Guest

Cisco MGX 8800 Series Switches

1.2.23 Release Notes for MGX 8230, MGX 8250, and MGX 8850 (PXM1)

 Feedback

Table Of Contents

Release Notes for Cisco MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.2.23

Contents

About These Release Notes

Features Introduced in Release 1.2.23

Features Introduced in Release 1.2.22

Features Introduced in Release 1.2.21

LMI AutoSense

addport

xcnfport

cnfport

dspport

MIB Changes

Features Not Supported in This Release

MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware

Service Module Redundancy Support

Network Management Features

Port/Connection Limits

SNMP MIB

Notes and Cautions

New Boot Image for FRSM-HS2, FRSM-2CT3 and FRSM-2T3E3 Cards

Using the restoresmcnf command

Loopback Plug on a HSSI:DTE Interface

UPC Connection Parameters

ForeSight and Standard ABR Coexistence Guidelines

RM Cell Generation

Reaction to Feedback Messages - Rate Up

Reaction to feedback messages - Rate Down

Fast-Down

Guidelines

Node Related

Connection Management Related

Documentation Corrections

New and Changed Commands in the 1.2.x Baseline

Limitations

CWM Recognition of RPM-PR and MGX-RPM-128M/B Back Cards

clrsmcnf

Problems after Power Cycle

Anomalies Fixed in Release 1.2.23

Anomalies Fixed in Release 1.2.22

Anomalies Fixed in Release 1.2.21

Known Anomalies for Platform Software Release 1.2.23 and Service Module Firmware

Anomaly Status Changes in Release 1.2.23

Compatibility Notes

MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Certification with Other Products

Boot File Names and Sizes

MGX 8250 and MGX 8850 (PXM1) Firmware Compatibility

MGX 8230 Firmware Compatibility

Comparison Matrix

RPM Compatibility Matrix

MGX 8850 (PXM1), MGX 8250, and MGX 8230 Release 1.2.23 Hardware

Special Installation and Upgrade Requirements

Special Instructions for Networks Containing FRSM-2-CT3

Executing the Script

Script Functionality

Upgrade Procedure for Non-Redundant PXM

Upgrade Procedure for Redundant PXMs

Instructions to Abort PXM Upgrade

Aborting an Upgrade from Release 1.1.3x and Above

Aborting an Upgrade from Release 1.1.2x

Service Module Boot/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

Historical Information from the 1.2.x Baseline

Features Introduced in Release 1.2.20

AUSM CAC Based on SCR in VBR

Features Introduced in Release 1.2.13

Additional PXM1 Stats and NBSM Stats for AUSM and FRSM

Command to Terminate a Telnet Session

Features Introduced in Release 1.2.11

RPM Automatic Cellbus Double Clocking

Enhanced Alarm Filtering

Features Introduced in Release 1.2.10

AUSM-8T1E1 Egress Channel Counters

PXM-UI-S3 Secondary BITS Clocking

VISM-PR Front Cards

Features Introduced in Release 1.2.02

Configuring the Cellbus Clock (CBC) Rate

Features Introduced in Release 1.2.01

Standard ABR on FRSM-VHS Modules

APS Support on SRM-E

Features Introduced in Release 1.2.00

FRSM-HS2/B

SRM-E

ITU APS Annex-A, All Configurations Supported on PXM1

CESM 8T1 Model B

PXM-UI-S3

Problems Fixed in Release 1.2.20

Problems Fixed in Release 1.2.13

Problems Fixed in Release 1.2.11

Problems Fixed in Release 1.2.10

Problems Fixed in Release 1.2.02

Problems Fixed in Release 1.2.01

Problems Fixed in Release 1.2.00

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 MGX 8230, MGX 8250, and MGX 8850 (PXM1), Software Version 1.2.23


Contents

About These Release Notes

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription.

Note that for Release 1.2.23, the user documentation (command reference, overview, and installation and configuration guides) were not updated. Use the existing documents in addition to this release note.

Product documentation for MGX 8850 (PXM1) is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/index.htm

Product documentation for MGX 8250 is available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/index.htm

Product documentation for MGX 8230 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/index.htm

Product documentation for VISM is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/

Product documentation for RPM is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/rpm/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/rpm/index.htm

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

Features Introduced in Release 1.2.23

This is a maintenance release that includes bug fixes only. There are no new features introduced with this release

Release 1.2.23 supports all features introduced in prior releases. (See the "Features Not Supported in This Release" section and the "Historical Information from the 1.2.x Baseline" section.)

Features Introduced in Release 1.2.22

Release 1.2.22 supports all features introduced in prior releases. (See the "Historical Information from the 1.2.x Baseline" section.)

Features Introduced in Release 1.2.21

Release 1.2.21 supports all features introduced in prior releases. (See the "Historical Information from the 1.2.x Baseline" section.)

LMI AutoSense

The LMI AutoSense feature on the Frame Relay Cards on MGX switches enables a frame relay port to detect the LMI type supported by the frame relay CPE (customer premise equipment). This autosensing feature avoids the need to configure the LMI type on each frame relay port.on the FRSM-8T1/E1 and FRSM-VHS(2CT3, 2T3, 2E3, 2HS2, 2HS2B) cards on the PXM platform.

The LMI AutoSense feature is supported for Frame Relay and FUNI port types. It is not applicable for Frame Forwarding port types. The detected LMI types will be of the following UNI types:

AnnexD-UNI

AnnexA-UNI

StrataLMI

The LMI AutoSense feature is not supported on NNI interfaces.

The LMI AutoSense feature is configurable at a per port level.

A new MIB variable portLmiSigConfMethod has been added to the existing frPortCnfSigLMIGrpTable MIB table.

The addport, cnfport, xcnfport and dspport CLI commands have been modified to configure/display the new portLmiSigConfMethod MIB variable.

addport

One more parameter lmi_autosense will be added to the addport CLI, which can be optionally specified by the user while adding the port. By default the value will be set to Manual(1).

If the user wants to configure the port for LMI AutoSense, the user needs to set the lmi_autosense parameter value to AutoSense(2) while adding the port using addport.

The addport command syntax for the cards will thus be modified to as shown below

FRSM-8P and FRSM-2CT3.

Syntax:

addport "port_num line_num ds0_speed begin_slot num_slot port_type [lmi_autosense]"

where lmi_autosense can be configured for either mode Manual(1) or AutoSense(2)

FRSM-2T3, FRSM-2E3, FRSM-HS2, FRSM-HS2B.

Syntax:

addport "port_num line_num port_type [lmi_autosense]"

xcnfport

One more parameter "-lmias" has been added to the xcnfport CLI, which can be specified while either adding the port or modifying the port using xcnfport. By default the value is set to Manual(1).

To configure the port for LMI AutoSense set the "-lmias" parameter value to AutoSense(2) while addding/modifying the port using xcnfport. At the same time, set the port signalling protocol type to noSignalling using the "-sig" option.

The xcnfport command syntax for the cards has been modified as shown below.

Syntax:

xcnfport "-pt <PortNum> -ln <PortLineNum> -en <PortEnable> -rat <PortEqueueServiceRatio> -flag <PortFlagsBetweenFrames> -asy <AsynchMsg> -t391 <T391Timer> -t392 <T392Timer> -n391 <N391Counter> -n392 <N392Counter> -n393 <N393Counter> -enhancedLmi <enhancedLmi> -pta <portAdmin> -svcen <portSvcStatus> -svcuse <portSvcInUse> -pbe <portBertEnable> -m32eqth <EgressQueueThreshold> -lmias <lmi autosense>"

where -lmias <lmi_autosense> can be set to either 1 for Manual or 2 for AutoSense.

cnfport

One more parameter lmi_autosense has been added to the cnfport CLI, which can be specified while modifying the port. By default the value is set to Manual(1).

To configure the port for LMI AutoSense set the lmi_autosense parameter value to AutoSense(2) and lmiSig to noSignalling while using cnfport.

The cnfport command syntax for the cards has been modified to as shown below:

Syntax:

cnfport "portNum lmiSig asyn ELMI T391 T392 N391 N392 N393 [lmi_autosense]"

where [lmi_autosense] can be set to either 1 for Manual or 2 for AutoSense.

dspport

The existing CLI dspport will be enhanced to display the value of the new MIB variable. The display of this new variable portLmiSigConfMethod will be added between the display of PortSpeed and SignallingProtocolType.

Example:

node.1.4.VHSHS2.a > dspport 1
    SlotNum:                      		4
    PortLineNum:                  		1
    PortNum:                      		1
    PortRowStatus:                		Add
    PortDs0Speed:                 		notUsed
    PortDs0ConfigBitMap(1stDS0):  		0xffffff(1)
    PortEqueueServiceRatio:       		n/a
    PortFlagsBetweenFrames:       		0
    PortSpeed:                    		51840 kbps
    portLmiSigConfMethod:             Manual
    SignallingProtocolType:       		NoSignalling
    AsynchronousMsgs:             		UPD_UFS disabled
    T391LineIntegrityTimer:       		10 sec
    T392PollingVerificationTimer: 		15 sec
    N391FullStatusPollingCounter: 		6
    N392ErrorThreshold:           		3
    N393MonitoredEventCount:      		4
    EnhancedLmi:                  		Off
    PortState:                    		FailedDuetoLineFailure
    PortSignallingState:          		No Signalling Failure
    CLLMEnableStatus:             		Disable
    CLLMxmtStatusTimer:          		 40 ms
    portType:                     		frameRelay
    portEnhancedSIW:              		Disable
    PortIngrPercentUtil:          		0
    PortEgrPercentUtil:           		0
    PortOversubscribed:           		False
    PortSvcStatus:                		Disable
    PortSvcInUse:                 		Not In-Use
    PortSvcShareLcn:              		Card-based
    PortSvcLcnLow:                		0
    PortSvcLcnHigh:               		0
    PortSvcDlciLow:               		0
    PortSvcDlciHigh:              		0
    PortNumNextAvailable:         		2

MIB Changes

frPortCnfSigLMIGrpTable MIB Table

In support of LMI AutoSense, the new MIB object portLmiSigConfMethod has been added to the end of the frPortCnfSigLMIGrpTable MIB table.This MIB can hold either of the two values 1) Manual, 2) AutoSense. By default the value of the MIB will be set to "Manual". While enabling the port, the MIB can be used to configure the port to AutoSense LMI. After reset or softswitch the MIB retains its values to what was configured before reset.

portLmiSigConfMethod OBJECT-TYPE
    SYNTAX  INTEGER {
            manual    (1),
            autosense (2)
            }
    ACCESS  read-write
    STATUS mandatory
    DESCRIPTION
        " This object enables/disables the port LMI signalling autosense.
Setting this object to autosense(2) enables the port to autodetect and configure port LMI 
signalling type.
When this object is set to manual(1), user needs to manually configure the port LMI 
signalling type using the SignallingProtocolType mib.
        "
    DEFVAL { manual }
    ::= { frPortCnfSigLMIGrpEntry 11}

trapConfigChange MIB Table

The new MIB PortLmiCnfType is configurable using snmpset and the value of the mib can be accessed using snmpget. Once the MIB is set for LMI autosense, autodetection happens and the detected LMI type will be set and also the config change trap (trap no 50600 for PXM1-based MGX platforms) will be sent indicating the detected LMI type.

trapConfigChange  TRAP-TYPE
        ENTERPRISE      basis
        VARIABLES       {
                         lastSequenceNumber,
                         shelfNodeName,
                         shelfNum,
                         moduleSlotNumber,
                         moduleTrapAlarmSeverity,
                         functionModuleType,
                         configChangeTypeBitMap,
                         configChangeObjectIndex,
                         configChangeStatus
                        }

        DESCRIPTION
                "Sent when the config has changed.
                 The bit map tells if the change on
                 line/port/channel and the object
                 index shows the line#/port#/channel#,
                 the status shows if it's an add or
                 mod or del.
                "
        ::= 50600

Configuration Upload

A new MIB object has been added to the Configuration File for upload. The new MIB object is included at the end of the existing Signalling port table configuration information.

Features Not Supported in This Release

Layer 2 support as an AutoRoute routing node

Interworking with Cisco 3810

MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware

The following MGX 8220 hardware has been superseded by MGX 8850 hardware.

The MGX-SRM-3T3/C front card replaces the original AX-SRM-3T3 front card and the MGX-BNC-3T3 back card replaces the original AX-BNC-3T3-M back card. Both the AX-SRM-3T3/AX-BNC-3T3-M 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-SCSI2-2HSSI/B, which works with the MGX-FRSM-HS2 and MGX-FRSM-HS2/B front card.

The AX-CESM-8T1 is superseded by the MGX-CESM-8T1/B.

The AX-AUSM-8T1 and AX-AUSM-8E1 is superseded by the MGX-AUSM-8T1/B and MGX-AUSM-8E1/B, respectively.

Service Module Redundancy Support

MGX 8850 (PXM1) 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.

Table 1 Service Module Redundancy Support 

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-8T1/B

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-HS2/B

with HSSI back card, 1:1 redundancy
with 12IN1-8S back card, no 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

MGX-VISM-PR-8T1

1:N redundancy

MGX-VISM-PR-8E1

1:N redundancy

Note Support for 1:N redundancy is provided in conjunction with an MGX-SRM-3T31 card or an MGX-SRM-E2 card.

1 SRM-3T3 cards only support bulk Distribution for T1 lines.

2 Bulk Distribution is supported for T1 and E1 lines using the SRM-E card.


Network Management Features

Network management features are detailed in the CWM Release 12 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 new FRSM-HS2/B 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 2 for detailed connection information.

Table 2 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/B

HSSI

2000

2

2

560

898

 

12IN1-8S

4000

8

8

560

898

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

192

4

4

192

192

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-8T1/B

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

248

560

898

 

SMB-8E1

1000

8

248

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 MGX 8230 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. Maximum number of PXM UNI connections supported is still 4000 (as in prior releases).

SNMP MIB

The MGX 1 MIB naming convention has been changed as of the 1.2.10 release. The MIBS provided with Release 1.2.23 are named mgx1rel1223mib.tar.

The MIBs are bundled in the firmware bundle posted to CCO.


Note The old_mib_Format has been discontinued as of the 1.2.10 release As of the 1.2.10 release the new_mibFormat will be named mgx1rel<releasenumber>mib.tar


Notes and Cautions

The following notes and cautions should be reviewed before using this release.

New Boot Image for FRSM-HS2, FRSM-2CT3 and FRSM-2T3E3 Cards

There is a new FRSM Boot image for the FRSM-HS2, FRSM-2CT3 and FRSM-2T3E3 cards. The image is only required for the fix for CSCdz18745 (See "Anomalies Fixed in Release 1.2.21" on page 25 for additional information).

To upgrade the boot image, please follow the procedure in Service Module Upgrades.

Using the restoresmcnf command

Before using the restoresmcnf command, you must issue a clrsmcnf to make sure that there are no dangling connections after the restoresmcnf command.

Loopback Plug on a HSSI:DTE Interface

Using a loopback plug on a HSSI:DTE interface is not supported and can bring the node down.

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.

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.

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.

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.

Node Related

A maximum of one BERT test can be performed per bay at any point in time. The command addln should be issued before executing the addapsln command.

If you are moving service modules from an existing MGX 8220 platform to the MGX 8850 (PXM1), MGX 8250, or MGX 8230, 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 (PXM1), MGX 8250, or MGX 8230 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 (PXM1), MGX 8250, or MGX 8230.

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 (PXM1), MGX 8250, or MGX 8230 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 (or MGX 8250 /MGX 8230) Installation and Configuration publication on the documentation CD.


Step 1 Use ftp to port the MGX 8220 Release 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 > 
bin 
put <boot filename> AXIS_SM_1_<slot#>.BOOT 


To insure that TFTP downloaded the appropriate boot code, perform the following procedure to verify the flash checksums.


Step 1 Log into the shelf.

cc <slot #> 

Step 2 Verify that the two checksums are the same.

chkflash

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 (PXM1) 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 command clears the network IP addresses. IP addresses and netmasks stay the same (dspifip). However, Cisco recommends entering the cnfifip command to reconfigure the network IP addresses. 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 for syntax.

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 (PXM1) supports 15 simultaneous Telnet sessions and up to 10 TFTP sessions per shelf.

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 by locking the actuator.


Note When the card is reinserted the PXM automatically comes out of sleep mode.



Caution Cooling and Power limitations: 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 (PXM1) requires a minimum of one power supply per line cord to support the power requirement for five cards (see Table 3).

Table 3 Number of Power Supplies Per Line Cord Based on Cards Supported

 
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 (PXM1) 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).

Documentation Corrections

The documentation for the PXM1-based MGX switches incorrectly describes the Cellbus to slot assignments.

For example, the MGX 8250 with a PXM1 has 8 cellbuses. The distribution of these 8 cellbuses to the appropriate slot numbers can be found executing the CLI command dspcbclk.

m8250-4a.1.8.PXM.a > dspcbclk
  CellBus    Rate (MHz)     Slot     AutoClkMode
    --------------------------------------------------
       CB1         21           1, 2       disable
       CB2         21           3, 4       disable
       CB3         21           5, 6       disable
       CB4         21        17 - 22       disable
       CB5         21          9, 10       disable
       CB6         21         11, 12       disable
       CB7         21         13, 14       disable
       CB8         21        25 - 30       disable

New and Changed Commands in the 1.2.x Baseline

Table 4 lists the new and modified commands in Release 1.2.x baseline.

Table 4 New and Modified CLI Commands in the 1.2.x Baseline 

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
SRM-E1

addcon

Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.

The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.

CESM2

adddiagtest

Diagnostics.The diagnostic commands are modified for test number 8-SRM M13 Access. This command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot. Refer to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.1.40 at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/14/rnotes/rn1140.htm

SRM-E

addlink

Bulk redundancy/distribution. The existing command addlink is modified to link a certain number of T1/E1 channels from a bulk interface on SRM-E to a service module's T1/E1 lines. This command checks the card type of the service module in the target slot. The service module must be a T1/E1 type, depending upon the tributary type configured for the SRM-E line using the cnfln command. A service module will switch all its lines to bulk mode even if only one line is mapped to a tributary from SRM-E.

Note You must enable the lines on the SRM-E cards (using the upln and cnfln commands) before you can configure them for distribution.

SRM-E

addln

Existing addln command is modified to support per line interface type configuration (used only with the 12IN1-8S). If the user doesn't specify <interface_type>, the default type V.35 is used.

FRSM-HS2/B

SRM-E

addlnloop

Physical interface. Existing command addlnloop is modified to add a logical loopback on a line on the new card. (SRM-E)

SRM-E

addport

One more parameter lmi_autosense has been added to the command where lmi_autosense can be configured for either mode Manual(1) or AutoSense(2).

FRSM-8T1/E1

FRSM-VHS6

addred

Redundancy activities. The existing command addred is modified to configure redundancy on the new card.

SRM-E

clralldiagtests

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

clralm

Managing alarms. Existing command clralm is modified to clear alarms on a line on the new card.

SRM-E

clralmcnt

Managing alarms. The existing command clralmcnt is modified to clear alarm counts on a line on the new card.

SRM-E

cnfbert

BERT activities. The existing command cnfbert is modified to configure a line or port for BERT and start the test on the new card.

SRM-E

cnfcacparm

New command introduced in 1.2.20 Release to configure CAC based on SCR in VBR.

CAC Based on SCR in VBR3

cnfclktype

Existing cnfclktype command is added to FRSM-HS2B to configure line clock type for V.35/X.21 interfaces. This command is valid on the FRSM-HS2B-12IN1 card.

FRSM-HS2/B

cnfdiagparams

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

clrdiagresults

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

cnfclklevel

Permits the user to set the STRATUM level desired. (S-3 Clocking)

PXM-UI-S3

cnfdiagtest

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

cnflink

Bulk redundancy/distribution. The existing command cnflink is modified to configure the link for T1 byte-sync mapping on the new card. For byte-sync mapping on sonet interfaces, the T1 framing format should be configured.

The framing format can be specified at line level for all links using the cnfln command. It can be then overridden on a per link basis using the cnflink command.

Note The cnflink command is not applicable to 3T3 back cards. Also, byte-sync mapping is supported only for Sonet --> T1 mapping. Therefore, this command is not applicable if an SRM-E's line are configured for SDH --> E1 mapping.

SRM-E

cnfln

Existing cnfln command is modified on FRSM-HS2/B to support new MIB objects.

Note Do not configure an interface to DTE mode when a physical loopback plug is plugged in. This will cause the line to go in and out of alarm and generate software errors on the PXM. If this situation occurs, use the command cnfln to configure the line as DCE to recover from the situation.

For SRM-E, cnfln command is modified to support new MIB objects and new enumerations for line rate.

For tributary type, option VT2 (carries E1 signals in Sonet) is not supported in this release.

For tributary mapping type, only option, 2 byte-synchronous mapping, is supported for T1.

FRSM-HS2/B

SRM-E

cnfport

One more parameter lmi_autosense has been added to the command which can be specified while modifying the port. The parameter lmi_autosense can be either mode -- Manual(1) or AutoSense(2).

FRSM-8T1/E1

FRSM-VHS6

cnfsrmcklsrc

Managing clock sources. Existing command cnfsrmclksrc is modified to support the new SRM-E card.

SRM-E

clrsrmcnf

Managing configuration. The existing command clrsrmcnf is modified to clear all card configuration including distribution links. The configuration cannot be cleared if redundancy is enabled.

SRM-E

delbert

BERT activities. The existing command delbert is modified to delete/terminate the operation in progress on the new card.

SRM-E

deldiagtest

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

dellink, delslotlink

Bulk redundancy/distribution. The existing commands dellink/delslotlink are modified to delete distribution links on the new card. After the last distribution link to a service module is deleted, the service module switches all its lines to non-bulk mode (to its back card).

SRM-E

delln

Physical interface. Existing command delln is modified to disable a line on the new card.

Note A line cannot be deleted if distribution links are configured for that line.

SRM-E

dellnloop

Physical interface. Existing command dellnloop is modified to delete a logical loopback on a line on the new card.

SRM-E

delred

Redundancy activities. The existing command delred is modified to delete the redundancy configuration on the new card.

SRM-E

delsesn

Use this command to terminate a UNIX-based telnet session.

delsesn <sesn no> [sesn no>] [sesn no>] ...

where sesn no is the number of the session in the range 0-15.

PXM4

dspalmcnt

Managing alarms.The existing command dspalmcnt is modified to display alarm counts on a line on the new card.

SRM-E

dspalm

Managing alarms. Existing command dspalm is modified to display alarms on a line on the new card.

SRM-E

dspalmcnf

Managing alarms. Display alarm configuration for a line.

SRM-E

dspalms

Managing alarms. Existing command dspalms is modified to display alarms on all lines of a slot on the new card.

SRM-E

dspapsln

 

ITU APS Annex-A
SRM-E1

dspbert

BERT activities. The existing command dspbert is modified to display the parameters and the results of an ongoing operation on the new card.

SRM-E

dspcacparm

New command introduced in 1.2.20 Release to display CAC parameters

CAC Based on SCR in VBR3

dspcd

The dspcd command on the CESM model B card is modified to display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards.

CLI changes

The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type and so on.

CESM2

dspclkinfo

Displays some extra information about second external BITS clock, as shown in the following screen example:

NOEXTCLK2 = OFF
extClock2Present = No
Last External Clock2 Present = 1

PXM-UI-S35

dspparifs

Displays the existence of interface 7.36 along with interface 7.35.

PXM-UI-S35

dspdiagresults.

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot

SRM-E

dspdiagtests

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.

SRM-E

dsplink, dspslotlink

Bulk redundancy/distribution. The existing commands dsplink/dspslotlink are modified to display distribution links.

SRM-E

dspln

Existing dspln command is modified on FRSM-HS2 B and SRM-E to display new objects.

FRSM-HS2/B
SRM-E

dsplns

Existing dsplns command is modified to display interface type.

FRSM-HS2/B
SRM-E

dsplog

The command dsplog will include SRME online diagnostics failure if it happens.

SRM-E

dspport

The existing CLI dspport will be enhanced to display the value of the new MIB variable. The display of this new variable portLmiSigConfMethod will be added between the display of PortSpeed and SignallingProtocolType.

FRSM-8T1/E1

FRSM-VHS6

dspred

Redundancy activities. The existing command dspred is modified to display the redundancy configuration on the new card.

SRM-E

dspsrmclksrc

Managing clock sources. Existing command dspsrmclksrc is modified to display the card types of the current and previous SRM card.

SRM-E

dspsrmcnf

Managing configuration. The existing command dspsrmcnf is modified to display the current card configuration on the new card.

SRM-E

modbert

BERT activities. The existing command modbert is used to modify BERT parameters.

SRM-E

pausediag
resumediag

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot

SRM-E

rundiagtest

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot

SRM-E

showdiagtests

Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot

SRM-E

softswitch

Redundancy activities. The existing command softswitch is modified to manually switch to the redundant module for the SRM-E.

SRM-E

switchapsln

The command is modified to include the following options:

3 = forced working-> protection

4 = forced protection->working

5 = manual working->protection

6 = manual protection-> working

ITU APS Annex-A

SRM-E1

switchback

Redundancy activities. The existing command switchback is modified to switch back to the primary module from the redundant module for the SRM-E.

SRM-E

xcnfalm

Managing alarms.The existing command xcnfalm is modified to configure alarms for a line on the new card. The xcnfalm command allows only DS3 and E3 alarm thresholds to be configured.

SRM-E

xcnfcon

Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.

The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.

CESM2

xcnfport

The option "-pbe " to enable/disable BERT on the port has been removed, since BERT is not supported at port level in VHS cards.

FRSM-VHS

xcnfport

In Release 1.2.21, one more parameter "-lmias" has been added. This new paramter can be specified while either adding or modifying the port. The parameter lmi_autosense can be either mode -- Manual(1) or AutoSense(2).

FRSM-8T1/E1

FRSM-VHS6

1 Added in Release 1.2.01.

2 Modified in Release 1.2.01.

3 Added in Release 1.2.20

4 Added in Release 1.2.13

5 Modified in Release 1.2.10

6 Modified in Release 1.2.21.


Limitations

CWM Recognition of RPM-PR and MGX-RPM-128M/B Back Cards

CWM does not distinguish between the Ethernet back card versions installed with the MGX-RPM-128M/B or 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 (PXM1), MGX 8250, and MGX 8230:

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.


Note As designed, if RPM-PR is configured as a Label Switch Controller (LSC), execution of the clrsmcnf command on those LSC slots will be rejected.


Problems after Power Cycle

This limitation pertains to configurations on MGX 8250 and MGX 8230 nodes with RPM-PR cards.

Following a power cycle, some configurations of MGX 8230 or MGX 8250 may display problems. (The booting of some service modules, RPM-PR cards and/or the standby PXM1 card are impacted.) The following must be true for this problem to occur:

1) RPM-PR cards must have configuration on the PXM HD.

2) There have to be RPM-PR cards on the shelf.

3) There have to be SRM cards on the shelf.

4) There has to be core card redundancy

The workaround is to reset the impacted card(s) to clear the problem (see CSCeb02400).

Anomalies Fixed in Release 1.2.23

Table 5 lists the problems fixed in the service module firmware and the Release 1.2.23 software as of 8/26/04. 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.

Table 5 Anomalies Fixed in Service Module Firmware for Release 1.2.23 

Bug ID
Description

CSCed92515

Bring VxWorks source into the VOB; fix timer wrap around after 466 days

CSCee51143

Bad clk signal on external clock source

CSCee95065

Reconfigure clk source when the pxm card comes to active state


Anomalies Fixed in Release 1.2.22

Table 7 lists the problems fixed in the service module firmware and the Release 1.2.22 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.

Table 6 Anomalies Fixed in Service Module Firmware for Release 1.2.22 

Bug ID
Description

CSCec14559

PXM spontaneously fails over during 1:N RPM redundancy testing

CSCee08054

Change the DMA semaphore timeout value for QE to 3 seconds.

CSCee20455

port resync on MGX8250 updates the wrong port id


Anomalies Fixed in Release 1.2.21

Table 7 lists the problems fixed in the service module firmware and the Release 1.2.21 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.

Table 7 Anomalies Fixed in Service Module Firmware for Release 1.2.21 

Bug ID
Description

CSCdt90915

Symptom: When using the addlnloop command on a PXM card and specifying a remote line loop, the line was put in local line loop instead.

Conditions: remote loop using addlnloop

Workaround: Use the cnfln command to put the line in remote/local loopback.

CSCdu72687

Symptom: Can't change donothold from front card from CiscoView.

Conditions: Always

Workaround: Use CLI

CSCdy43226

Symptom: After a successful provisioning, deleting a port from CWM GUI caused the FRSM slot 5 to reset and switch to redundancy slot 14.

Conditions: PXM FW is 1.2.01 FRSM FW is 10.2.01

Workaround: Softswitch the FRSM back to primary and the FRSM is functioning normally.

Further Problem Description: There is a software error 20208 and multiple Task failed before the FRSM reset.

CSCdy55509

Symptom: When softswitch is done, incorrect Alarm comes up even thought some of the information say no alarm/error.

Conditions: MGX 8850 (PXM1) Rel: 1.1.41 FRSM-8T F/W: 10.0.24 Y-redundancy

Workaround: 1, delred and then resetcd FRSM card. 2, delcon/addcon

CSCdy84940

Symptom: Entering the command dncon on the slave side returns that the command was not executed, but it discards two frames each time you enter command.

Condition: Entering the command dncon on the slave side.

Workaround: unknown

CSCdz16976

Symptom: Customer added port on AUSM cards and the port did not appear on the PXM.

Conditions: Creating port on MGX1 with PXM1 processor and AUSM card, the port is created on the service module but fails to appear on the PXM. The log contains the port add, dspports on the service module shows the port, but dsparifs on the active PXM does not have the port.

Workaround: Delete the port on the AUSM card and perform a softswitch. The port can then be added.

CSCdz53938

Symptom: The active controller card resets do to a software error and a core dump is generated. The error states a tRootTask with the SYS-TASKLOSTFATAL message seen in the log.

Conditions: Running as normal no conditions found

Workaround: NONE

CSCea00417

Symptom: Error RED-7-BAD_SHLF_SLOT logged after softswitch 1:N RPM redundancy. Consecutive Softswitch's causes the STDBY RPM to get stuck in Reserved state

Condition: Problem observed on MGX nodes and on H/W RPM/B and RPM/PR cards

Workaround: No workaround for the error RED-7-BAD_SHLF_SLOT, although not service affecting, RPM Hardware replacement and PXM switchCC did not clear error. Remove/reseat the RPM stuck in Reserved state will clear the issue and return the card back into STDBY state

CSCea38011

Symptom: xcnfchan is not working properly.

Condition: On FR-FR-connections, if you use xcnfchan command to change the value, it comes with the error message. But it changed the value. On slot 13 has DLCI 209 which is going to slot 3 port 1 DLCI 209. when I changed the pcr 88542 to 40000 on the DLCI 209, it comes with the error but it changed the value.

Workaround: Unknown

CSCea41394

Symptom: Circuit Emulation (CES) slave SPVCs endpoints do not interoperate with Cisco IOS PNNI devices supporting CES (LS1010, c8500).

Call setups from 8540 are rejected in the MGX. The CES SPVCs are created as CBR.1, and CBR.2 and CBR.3 should also be allowed to be configured to allow interoperability.

Conditions: Using CES SPVCs with a CESM card in an MGX switch.

Workaround:

None.

CSCea47460

Symptom: Value of the port is not changed when executing these commands.

Condition: When the xcnfport command is executed to change the value of enhanced SIW, and portbert enable.

Workaround:

none

CSCea49991

Symptom: LMI signalling on a port is not auto configurable.

Conditions: When Port is enabled.

Workaround: None.

Further Problem Description:

LMI signalling on a frsm port is not auto configurable, This is a new feature enhancement to enable the port to autodetect the uni signalling type from the status enquiry received from the connected CPE.

CSCea52854

Symptom: New PVCs added on FRSM may experience abit corruption.

Conditions: Adding new PVCs (possibly only when added by the CWM Service Agent, and also when added in quick succession - i.e., many connections added in a bulk operation)

Workaround: Run a preventative script to patch FRSM memory.

Further Problem Description: Not ALL new connections are corrupted - only when the MGX log shows

03/21/2003-06:54:13 20 clt        FRSM-6-4051                 
 Channel out of alarm: LCN #25  

then the corruption has definitely taken place (even though the PVC is healthy and never went out of alarm at all).

Also check the channel's abit sending status with FRSM command

dspchancnt

You may see that

                                  Tx                    Rx
                             ---------------       ---------------
  AbitState:                      Off                   Off

CSCea58097

Symptom: Port get oversubscribed as xcnfcon fails because of NAKs received from the processor card

Conditions: Add a abr connection and then modify pcr01, Modification fails. Then modify abrmcr value, modification fails but structures used for CAC get corrupted.Verify with dspload command Thus on addition of a new connection gives Channel Oversubscription message.

Workaround: Do softswitch, after softswitch the CAC structures are recalculated based on the configuration stored in the processor card.

CSCea64860

Symptom: When FRSM starts restarting, line alarm becomes fail. Then "Line alarm on" event is logged on dsplog. After that, FRSM becomes active, line alarm becomes clear. But MGX does not output "Line alarm off" events on dsplog. This may cause that MGX does not send line alarm clear traps to CWM.

Conditions: It is considered as a problem when the backcard is connected to DACS. If backcard is connected to non-DACS equipment (like as router), line status becomes fail again and line alarm clear event will be logged when it is cleared.

Workaround: None.

CSCea69277

Symptom: xcnfln is not allowing to change the E3 line speed

Conditions: Try executing the following command

xcnfln -e3 2 -dsusel 4 -dsulr 34099

Workaround: None

CSCea73317

Symptom: DLCI field in Channel delete trap (50389) shows a huge negative value or -1. Due to this problem, CWM is not able to delete connection from its database.

Condition: When the channel is deleted either from CWM or from CLI of the switch.

Workaround: None

CSCea78415

Symptom: xcnfchan does not function properly.

Condition: On FR-FR-connections, if you use xcnfchan command to change the value, it comes with the error message. But it changed the value. On slot 13 has DLCI 209 which is going to slot 3 port 1 DLCI 209. when I changed the pcr 88542 to 40000 on the DLCI 209, it comes with the error but it changed the value.

Workaround: None

CSCea81210

Symptom: dspportcnt and dspchancnt is not showing the correct kbpsAIR after 60000 frames

Condition: On FRSM cards, dspportcnt and dspchancnt does not show the correct KBPS AIR after 600000 frames reached. We need to clear the port counter and channel counters to get the correct KBPS AIR.

Data set is connected to frsm8t1 and sending traffic at the rate of 1500 kbps continuously. When the total frames reached 600000, then the kbps AIR is not showing the correct speed it receives and sends the data. Instead of showing 1500 kbps it shows some random value of 130 kbps. After we clear the port counter using clrportcnt, it started showing the correct value.

The problem is when we clear the port counter, we clear all the previous traffic data. Support personnel may find difficult for trouble shooting. If they clear the port counter to see the rate at which the port receives then they may lose some valuable trouble shooting information

Workaround: None

CSCea89014

Symptom: SM not responding to various CLI commands

Condition: This condition happens when there is traffic in the ingress direction on a port while the port is being added. Even under these conditions the probability is very low. A data frame has to arrive at the exact moment the framer chip programming is taking place. The results are seen after cc'ing to the SM via the command line.

Workaround: please use softswitch or switchredcd depending on the platform.

CSCeb01148

Symptom: After downloading an SM image and resetcd, the PXM gets an exception and the qe0 task gets suspended. However, the card didn't reset.

Conditions: When qe0 task gets suspended the pxm card is not resetting.

Workaround: Reset the pxm card.

CSCeb02400

This anomaly pertains to configurations on MGX 8250 and MGX 8230 nodes with RPM-PR cards.

Symptom: Following a power cycle, some configurations of MGX 8230 or MGX 8250 may display problems. (The booting of some service modules, RPM-PR cards and/or the standby PXM1 card are impacted.)

Condition: The following configuration information must be true:

1) RPM-PR cards must have configuration on the PXM HD.

2) There have to be RPM-PR cards on the shelf.

3) There have to be SRM cards on the shelf.

4) There has to be core card redundancy

Workaround: Reset the impacted card(s) to clear the problem.

CSCeb11365

Symptom: Able to modify the chanServType of a channel.

Condition: Using xcnfchan, we can change the chanServType from any type to any other type. This should not be allowed.

Workaround: None. If you don't use xcnfchan to modify the chanServType, you don't have any problem.

CSCeb12188

Symptom: FRSM-2ct3 cards that have full configuration are in fail state and dspcds shows "Empty resvd/empty".

Condition: The problem occurred while upgrading the node.

Workaround: None

CSCeb15100

Symptom: cnfport on FRSM is not taking the UFS enabled (3) and UPD-UFS enabled option

Condition: cnfport on the FRSM is not taking the option of UFS enabled (3) ad=nd UPD-UFS enabled (4). The options are mentioned in the command. But when it is executed it gives an error.

Workaround: Unknown

CSCeb19766

Symptom: Port counters on FRSM8E1 is not showing the frames discard counter incrementing for a mismatched LMI frames

Condition: On Slot 19 line 5 and line 6 are connected through cross able. I configured the LMI on one port as Annex D NNI and another port Annex A NNI. There is LMI mismatch and I could see the signaling failure and LMI failure on the ports. That looks normal.

In the dspportcnt, I see uni signaling time out and Xmt frames during LMI alarm counters are increasing. But I do not see the rec frames discard for the mismatch LMI frames. All those LMI mismatch frames are not discarded at the port level.

Workaround: unknown

CSCeb25306

Symptom: On a PXM1e shelf, after doing runrev, CESM-8t1e1 card does not stay in ACTIVE state, it keeps resetting.

Conditions: Issue runrev on a CESM card.

Workaround: None.

CSCeb32770

Symptom: Cannot issue config commands on AUSM

Conditions: Add a connection with CAC enabled on a port. The add connections with CAC disabled and oversubscribe the port. Issue config commands on the connection with CAC enabled modification fails due to oversubscription

Workaround: Issue config commands with CAC disabled, modification will be successful

Further Problem Description: None

CSCeb32940

Symptom: Secondary card reset twice because of imacore ABORT before becoming active when Primary card was removed

Conditions: When the ima state change events received from the other end is very rapid

Workaround: None.

CSCeb45194

Symptom: FRSM-VHS does not generate backward RM cells

Condition: FRSM port does not receive ingress traffic - i.e. two-way traffic does not exist

Workaround: Unknown

CSCeb47331

Symptom: Auto sense LMI on FRSM-VHS cards (only) resets the standby card

Condition: Auto Sense LMI configured on the FRSM-VHS cards (FRSM-HSSI and FRSM2T3E3) resets the standby card. This is not happening on FRSM-8T1/E1 and FRSMV35/X21(V35 does not support redundancy anyway)

Whenever we change the LMI type on the CPE side say from Annex A to Annex D, the FRSM-VHS card detects it and configure the LMI accordingly. But it resets the standby card. Again LMI works fine. If you configure the LMI using manual, then there is no issue. slot 3 line 1 port 1 is connected to HSSI interface. configured on the port 1 as Auto sense LMI. Whenever I change the LMI on the router, then FRSM-HSSI detects the LMI and as soon as it detects the LMI, it resets the standby card. I also checked with FRSM2T3 card, another FRSM-HSSI card all are having the same issue

Workaround: LMI can be configured using manual using cnfport 2 s y n instead of selecting the auto sense

CSCeb51809

Symptom: FRSM-8T1 card resets.

Condition: Configure remote loopback BERT on the card on a MGX8250 and MGX8850 PXM1 shelf.

Workaround: None.

CSCeb59256

Symptom: connection addition fails with "LCN 16 SarLcnEnb failed" error.

Conditions: while adding connections on the card.

Workaround: none

CSCeb61044

Symptom: Sometimes issuing the CLI command with wrong option or parameter would cause the PXM to reset.

Conditions: This sometimes happens when a user runs a multi-page CLI command, then leaves the output hanging, waiting on the "Hit return to continue or q to quit:" prompt.

Similar impact can be done by the following sequence:

1. Disconnect the telnet session before quitting out of the CLI command output

2. Immediately login back to a Service Module (any SM). Within 30 seconds the problem will be started.

Workaround:

Preventive measure:

Execute CLI commands cautiously

Users should not leave the terminal waiting for the user input too long.

Users should not close the terminal window without quitting.

Use CWM for provisioning -- this reduces the chances of running into the problem.

Further Problem Description: This occurs when a user does the following sequence of actions:

1. Logs in through a terminal emulator window using telnet

2. Runs a command that will have multiple screens of output. At the "Hit return to continue or q to quit:" prompt, does one of the three following things:

Leave the window to timeout by itself (this is the least probable means of reproducing the bug)

Disconnect the telnet session

Destroy the terminal emulator window

3. Logs in again after destroying a session and CC to an SM.

Detail:

A certain error message is printed due to the invocation of an ISR. This printf message is sent to the terminal and console.The message appears since a callback function is installed to handle the TIMEOUT (if the user doesn't enter anything after executing a multi-screen command in Page mode, like dsplogs, dsperr). Under this condition the callback function which executes in an ISR context fails and it invokes a PRINTF statement. This locks the PRINTF MUTEX semaphore.

After the PRINTF MUTEX semaphore is locked, two actions can cause the problem to happen:

Repeat Step 3 above

Perform any command that will cause invocation of PRINTF from a ON-CLI task.

These actions will cause the task to hang on the MUTEX semaphore and eventually reset within 12 minutes. e.g.: adding bulk distribution on an already used line (syntax has to be correct, but at least one argument should have an invalid value).

CSCeb62056

Symptom: CWM is not syncing up with MGX1 nodes

Conditions: When sonet lines and links are configured on the node

Workaround: None

CSCeb69150

Symptom: PXM1E reports port alarms on AUSM IMA ports after port failure is cleared.

Condition: AUSM IMA port failure by removing all lines, then replacing them until line failures are cleared.

Workaround: Reset card to clear port alarms.

CSCin27369

Symptom: For the CLI cnfchanq on AUSM card, for the parameters "CLP Thresh Low" and "EFCI Threshold" the acceptable range is given as 1through 16000, but it takes 0 also.

Conditions: None

Workaround: Unknown.

CSCin46617

Symptom: Inconsistency in DiagProxy & GUI behavior after stopping Bert on 8250.

Condition: While deleting BERT from Proxy with invalid BERT line.

Workaround: None

CSCin48403

Symptom: PXM resets on executing dspslavecons command.

Conditions: This occurs on the MGX8230.

Workaround: None


Known Anomalies for Platform Software Release 1.2.23 and Service Module Firmware

Table 8 lists known anomalies in the service module firmware and the Release 1.2.23 software as of 8/26/04. 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.

Table 8 Known Anomalies in the Service Module Firmware and the Release 1.2.23 Software 

Bug ID
Description

CSCdv49211

Symptom: It has been seen that the CPE device is sending traffic to the FRSM-HS1/B but the FRSM-HS1/B is not receiving any traffic on the port.

The physical line is clear of alarms as seen in dspalms however, the port sees 0 traffic coming in, as seen in dspportcnt <cmdArg>port_num<noCmdArg>.

Conditions: This was seen with FRSM-HS1/B firmware 10.0.22 and PXM firmware 1.1.34.

Workaround: Execute the commands "addlnloop <line#>" and "dellnloop <line#>" on the line which has failed port.

CSCdv53678

Symptom: switchapsln clear command sometimes causes aps line switch over from active working line to the protection line.

Conditions: Under a specific sequence of actions and conditions, this problem occurred once.

Initial conditions: MGX 7.1 and BPX 1.1 working lines are active, all lines are clear. There is no last user APS request shown. PXM card in slot 7 is active.

Sequence of actions:

1. Disconnect MGX to BPX 7.1 fiber (just one fiber)

2. "switchapsln s 8" on MGX

3. Remove MGX slot 7 back card

4. "switchcc" on MGX

5. Remove MGX slot 7 front card

6. Insert MGX slot 7 back card with the previously disconnected fiber reconnected

7. Insert MGX slot 7 front card

8. "switchcc" on MGX

9. "switchapsln s 7" on MGX

Workaround:

1. Make sure at both ends the working card is active.

2. Make sure both working and protection lines on both sides are clear.

3. Delete APS on MGX and added it back.

CSCdv53678

switchapsln 1 c command causes aps line switch over

Symptom switchapsln clear command sometimes causes aps line switch over from active working line to the protection line.

Conditions: Under a specific sequence of actions and conditions, this problem occurred once.

Initial conditions: MGX 7.1 and BPX 1.1 working lines are active, all lines are clear. There is no last user APS request shown. PXM card in slot 7 is active.

Sequence of actions:

a. Disconnect MGX to BPX 7.1 fiber (just one fiber)

b. "switchapsln s 8" on MGX

c. Remove MGX slot 7 back card

d. "switchcc" on MGX

e. Remove MGX slot 7 front card

f. Insert MGX slot 7 back card with the previously disconnected fiber reconnected

g. Insert MGX slot 7 front card

h. "switchcc" on MGX

i. "switchapsln s 7" on MGX

Workaround:

1) Make sure at both ends the working card is active.

2) Make sure both working and protection lines on both sides are clear.

3) Delete APS on MGX and added it back.

CSCdv84864

Symptom: When adding a connection, get error message saying 'dlci already in use'

Conditions: unknown.

Workaround: Need to manually correct the situation.

CSCdv86457

Symptom: PXM1 counter is not accurate when packet size is 128.

Conditions: Whenever packet size of 128 is used for sending traffic between PE to PE, pxm counters in dspchancnt shows wrong value.

Workaround: None.

Further Problem Description: None.

CSCdw60302

Symptom: With 1+1 APS bi-directional configuration, working line 7.1 in YEL alarm, active line stays on working 7.1.

Conditions: Removed the Rx of the working line from remote end to cause YEL alarm (RDI-L) on the working line. Delapsln and Addapsln, then configured to bi-directional mode.

Workaround: Execute a switchaps with Lockout, then switchaps with Clear. Then the active line will switch to protection line 8.1.

Further Problem Description: This problem is due to line condition prior to APS configuration.

CSCdw60302

APS-B-PXM1: with WL in YEL alarm, delapsln & addapsln results WL active.

Symptom: With 1+1 APS bi-directional configuration, working line 7.1 in YEL alarm, active line stays on working 7.1.

Conditions: Removed the Rx of the working line from remote end to cause YEL alarm (RDI-L) on the working line. Delapsln and Addapsln, then configured to bi-directional mode.

Workaround: Execute a switchaps with Lockout, then switchaps with Clear. Then the active line will switch to protection line 8.1.

Further Problem Description: This problem is due to line condition prior to APS configuration.

CSCdx15975

Symptom: Upon a "switchcc", "resetsys" or power cycle when the active PXM is reset, the routes previously manually configured and shown in "routeShow" will disappear and will not be found on the new Active PXM card.

Conditions: Any activity which causes the Active PXM card to reset will result in route loss. This if only for the routes configured manually.

Workaround: Manually restore the routes again with "routeAdd" or routeNetAdd"

Further Problem Description: None.

CSCdx33779

Symptom: Customer is seeing error message of packet size too big on SNMP GET.Had to resend SNMP query. SNMP GET will give error message "Packet Size too Big."

Conditions: unknown

Workaround: resend the GET again.

Further Problem Description: snmp get sometimes get "packet too big" error from the mgx.

CSCdx36186

Symptom: Traffic drop seen on aborting an upgrade.

Conditions:

1. Graceful upgrade on PXMT3 from 1134 to 1210Av (dspupgrade = install; and newrev 12.10Av)

2. Also, same symptom observed during fallback from 1210Av to 1134.

(dspupgrade = newrev; and abort 1134)

Workaround: None known.

CSCdx46852

Symptom: Node went unreachable to the BPX. Service modules showed failed.

Condition

The pxm also showed CBC failures.

Workaround: Switchcc fixed the outage.

Further Description

The node went unreachable to bpx and the pxm reported all cards failed in dspcds. But the cards weren't in failed state. The pxm also showed online diagnostics

CBC asic monitor test failures. switchcc solves the problem.

CSCdx70775

Symptoms: incomplete connections on two different MGX nodes

Conditions: Unknown

Workaround: Unknown

CSCdy35102

Symptom: Cell loss occurs twice after CESM 1:N redundancy switches.

Conditions: Cell loss occurred twice after CESM 1:N redundancy switches. -1st cell loss occurred when CESM switches.(softswitch or reset of active CESM) -2nd cell loss occurred when the status of a new standby CESM changes from Boot to Standby.(97 seconds)

Workaround: None.

CSCdy39992

Symptom: Customer is performing tests in lab environment with CWM 10.4.10 patch 1 and MGX firmware 1.1.32 They have found during testing that a separate application used to produce stats reports is unable to process all stats files tftp'd from the MGX. Investigation has shown that the failed stats files have a corrupted Header which causes the external application to fail in its processing of the file. This is happening approx 1% of the time from 4 different nodes.

Conditions: This was found in a lab environment with the MGX 8250's running 1.1.32 and the CWM running 10.4.10 patch 1.

Closer examination of the Binary File converted to ASCII shows the third field does not contain the standard format.

Here is the corrupted header information > 1, 1, 1..2, 3, 0, 1, 60, 255 > 0, 8, 1_16, 1, ( stat type: 0 stat value: 2713 stat peak > value: 238), (> stat ty> We can now see a good header: > 1, 1, 1132, 14, 0, 1, 60, 255 > compared with a bad header: > 1, 1, 1..2, 3, 0, 1, 60, 255

This shows that the stats files is being changed to 1..2 instead of 1132 to show the release. This change is sufficient to cause and exception in the stats collection process and create inconsistent stat reports.

Workaround: NO workaround currently available.

Further Problem Description: None.

CSCdz04750

Symptom: The FRSM8 card does not correctly process incoming Frames with incorrect CRC-16

Condition: The FRSM8 card does not correctly process incoming Frames with incorrect Frame Check Sum sequence. The port should discard these "corrupt" frames under the port counter "RcvFramesDiscCRCError:". Instead the frames get sent into the network.

Workaround: unknown

CSCdz16976

PXM missing ports

Symptom:

Customer added port on AUSM cards and the port did not appear on the PXM.

Conditions:

Creating port on MGX1 with PXM1 processor and AUSM card, the port is created on the service module but fails to appear on the PXM. The log contains the port add, dspports on the service module shows the port, but dsparifs on the active PXM does not have the port.

Workaround:

Delete the port on the AUSM card and perform a softswitch. The port can then be added.

CSCdz59162

Symptom: MGX 8850 resets due to Secondary Cache error and creates a core dump. This causes a switchover to the current standby card.

Conditions: Core dump on Secondary Cache error enabled

Workaround: None required

CSCdz59162

Need functionality on PXM1 to recover form Secondary Cache (L2) error

Symptom: MGX 8850 resets due to Secondary Cache error and creates a core dump This causes a switchover to the current standby card.

Conditions: Core dump on Secondary Cache error enabled

Workaround: None required.

CSCea04133

PXM1-2T3 continuously resets when adding mngt pvc with both ds3s active

Symptom: When adding a management PVC on an MGX8230 with a PXM1-2T3E3 (a pvc to internal port 34) the PXM will reset (some times continuously).

Conditions: This will only happen a management PVC is added, (port 34 on the pxm) and only when both DS3 lines are added.

Workaround: By using a VPI other than 0 on the management port (34), the PXM will not reset.

CSCea74880

Symptom: Switchcc can cause switchover from inband clock to internal oscillator.

Conditions: PXM1 with T3 back card.

Workaround: Re-run cnfclksrc.

CSCea86502

Symptom: Invalid directory contents on the PXM disk

Conditions: The customer followed a sequence of steps and that caused this problem. This problem is 100% recreatable if these steps are followed

Workaround: While in FW directory, if the customer wants to go to root dir, he can use cd "/"

Further Problem Description: None

CSCea90349

Symptom: When adding a user with ANYUSER privileges certain commands that shouldn't be allowed to be work do work e.g. delchan. When you are logged on with the ANYUSER access level you're not allowed to delete a channel using the "delchan" command. If you cc to the PXM the "delchan" command works and the connection is deleted.

Conditions: Just add a user profile with ANYUSER privilege. If that user logs on and tries to delete a connection the problem can be seen.

Workaround: There is no workaround.

CSCeb05910

Symptom: PM parameters on NBSMs are not accurate

Condition: PM parameters on NBSMs are not accurate Line layer error counters remain at zero. On the other hand, the Path layer counters such as CRC and CRC ES do not correctly reflect the count.

Workaround: unknown

CSCeb18229

Symptom: For the PXM1, the major alarm LED on Standby PXM is left ON without any problems occurring.

Condition: Unknown

Workaround: Execute switchcc or resetcd <Standby slot#> to clear the major alarm.

CSCeb32911

Symptom: When the PSU fails in a mgx8250, although it is noted in the log and dspshelf, when dspcds is looked at it says that the shelf is clear of alarms. Also the BPX that the mgx feeds into also says it is clear of alarms.

Condition: PSU should fail.

WorkAround: -N/A-

CSCeb35363

Symptom: pnport becomes 'enablenotup' when delay of 249ms induced on one link of the IMA group, causing all user traffic to re-route despite VPC / IMA trunk in active state on the AUSM card for that trunk. The delay later reduced to 50ms but pnport does not recover.

Conditions: pnport becomes 'enablenotup' when delay of 249ms induced on one link of the IMA group.

Workaround: unknown.

CSCeb38846

Symptom: Remote Line/Port loopback option not available in FRSM8T1/E1 for MGX-2 which is available in MGX-1

Reports following error: emeapl36.7.PXM.a > cnfbert -cbif 17.1.0 -pat 1 -lpbk

15 -sbe 1 -en 4 Error!! Bert Pattern could not sync. Test failed Error!! BERT pattern could not sync.

Condition: feature not available in cnfbert command

Workaround: None

CSCeb40265

Symptom: clkfrequency threshold has the option of 1-5 on xcnfln/cnfln on the HS2/B card does not specify the individual value

Condition: xcnfln shows the clkfrquencythreshold 1-5. It does not explain what are the values meant. It did not say what the value of selecting 1 and etc.

Workaround: unknown

CSCeb59713

PAR: Cannot increase Max vpcconid with cnftrk

Symptom: PAR does not allow you to change the number of VPCs from the default.

Conditions: rev 1.2.02.

Workaround: None.

CSCeb75989

Symptom: PXM1 experienced a software error, dumped core, reset, and redundant card took over.

Conditions: Production network node, normal provisioning, stats collection, and grooming taking place.

Workaround: none.

CSCeb79964

PAR sets ABit Clear to channel, causing AIS towards CPE

Symptom: CPE connected to the AUSM-8T1 port receives AIS on a specific con. There are no line and port alarms. There are no remote alarms.

Conditions: Cisco 3810 connected to an AUSM-8T1 service module on a MGX1 shelf.

Workaround: None

CSCec36943

Clocking info not in MGX config files

Symptom: Under certain conditions, the clock source configuration information does not show up in CWM

Conditions: the information is not obtained through config upload.

Workaround: the switch can be queried through SNMP or CLI.

CSCec72985

PXM failing CBC ASIC

Symptom: Online Diags test sometimes fails for CBC Asic access check.

Conditions: Heavy traffic.

Workaround: None needed. If the CBC failures are consistent, and occur even under low traffic, then the PXM needs to be replaced.

CSCed28747

Watchdog Timeout due to PAR tasks

Symptom: PXM1 reset, with clean switchover to redundant PXM1.

Conditions: Normal operation.

Workaround: None.

CSCed64635

PXM switchover during SM bringup could cause SM to remain in BOOT state

Symptom: SMs seen in BOOT state

Conditions: PXM switchover to redundant PXM. SM reset before just about before the PXM switchover.

Workaround: resetcd SM physical slot

Further Problem Description: This is happening because the card bringup is event based. When the standby PXM becomes active, it does not get any event about the card rebooting, for the PXM to start the card bringup procedure.

CSCed81573

Tracking code review for Vxworks problem w/ semaphore (cant cc to card

Symptom: cc session to an FRSM_2E3 card would fail

Condition: None.

Workaround: None.

CSCee21093

tftp to RPM-PR card takes infinite long time get config file on PXM1

Symptom:

On MGX8850 with PXM1 controller card platform, tftp of the config file by the CWM NMS application from the RPM-PR card takes a long time to complete.

Condition: CWM NMS application tries to sync up with the MGX node - this process invokes a SNMP get route to collect information from the node cards. For some reason, the said RPMPR config file can't be collected as the SNMP get routine gets timed out. As the time out happens in this condition, CWM NMS application can't sync up with said RPMPR configuration.

Workaround: Remove the running configuration of the said RPMPR card by executing "clrsmcnf" from the PXM1 controller card. Reload the original configuration (which must be saved in a temporary file before executing clrsmcnf) on the RPMPR card. This should allow the card to resync properly with the CWM NMS application.

CSCee34710

FRSM-VHS fails to boot after a power cycle running 1.3.10

Symptom: FRSM-VHS fails to boot after a power cycle running 1.3.10, FRSM_VHS card should reboot if it doesn't receive SCM Polling message from PXM.

Workaround: None

CSCee35171

Watchdog timeout reset due to readNvRam

Symptom: Nothing specific seen as this is one time occurrence and there will be a watchdog timeout reset.

Conditions: None.

Workaround: None.

CSCee35196

During APS switchover, ensure the registers are programmed.

Symptom: In very rare situations, this problem can lead to traffic loss.

Conditions: None.

Workaround: None.

Further Problem Description: When an APS switchover is invoked, we program the register by writing it once. We don't cross check if this has gone through fine. Just to make things doubly sure, Write it five times and read.

CSCee40233

To resolve the ssiFunctrace issue

Symptom: card reset due to memory exception

Conditions: None.

Workaround: None.

Further Problem Description: Sometimes the card gets an memory exception due to wrong address formed by changes in some bit value

CSCee48365

Headline: QE Access Failed for QE1

Symptom:

Online diag QE access failure on QE1 chip one.

Online Diag test Failed. QE Access Unique ID: 5

ERROR - qe_RAM[2] Walking 1 test FAILED

Conditions:

If there is a connection with valid glcn 0x8000 & this connection is discarding cells due to high traffic rate. Online QE diag test can fail.

Workaround:

Prevent the use of 0x8000 glcn for a connection.

CSCee51143

Headline: Bad clk signal on external clock source

Symptom:

The signal of the clock source was divided and there was not enought ampltiude as the clock signal was not balanced.

Conditions:

Configure external T1 clock source and perform a switchc.

Workaround:

None.

Further Problem Description:

the balanced bit on the standby card was not set properly. Now the value for the balance bit is set properly and the ALT_TERM_Dis is set according value

CSCee61563

Headline: QE errors, Need to reset the pxm card when we have fatal QE errors

Symptom: When the QE has some fatal errors.

Conditions: Whenever the QE has some fatal errors, we need to reset the pxm card.

Workaround: None.

CSCef12424

Headline: RPM IPC FAILURE after pxm1 switchover with Power On reset

Symptom:

1. PXM1 switchover with Power On reset,no core file logged;

2. After PXM1 switchover,1:N RPM redundancy switchover because slot9 RPM IPC FAILURE;

3. Slot1 RPM is redundancy card for slot9 and slot10 RPM.slot9 switch to slot1;slot10 RPM in reserve state.

Conditions: None.

Workaround: None.

CSCef54552

Headline: ATM0 connectivity lost.

Symptom:

Whenever switchcc is performed, not able to reach node through management connection

Condition:

When using management connection from RPM to PXM, to login to node instead of ethernet port.

Work Around:

Whenever adding the management connection from RPM to PXM for 7.34 port on the active card, we need to reset the standby to make it sync with active.


Anomaly Status Changes in Release 1.2.23

Table 9 lists the known anomalies that have changed status in Release 1.2.23 as of 8/26/04. Changed status means that the anomaly changed from open in Release 1.2.22 to a state other than resolved. The workaround states the status (closed, junked, duplicate, or unreproducible).

Table 9 Status Change Anomalies in CWM Release 1.2.23 Software 

Bug ID
Description

CSCdw51070

CBC Access test fails hardware is clear after reset

Symptom: dspdiagresults show that the CBC access test fails multiple times.

Conditions: Happens spontaneously.

Workaround: None.

Further Problem Description: The PXM was reset and the CBC error shown in the cbcDspCounts command disappeared but the CBC access test still fails.

Status Change: Closed

CSCdx16223

Symptom: Unable to telnet to PXM. Console access ok to both active and standby PXM. In the console access doing "ll" you will see the following error message "IO Error

- can't stat file: S_iosLib_TOO_MANY_OPEN_FILES"

Conditions: When the switchcc or automatic switchover happened when tftp get/put is happening. After the switchover, the pxm will have telnet/console access. Then do multiple savesmcnf, saveallcnf etc.

Workaround: switchcc

Further Problem Description: When a switchover happens when there is a active file download between active and standby card, the newly active card will start losing descriptors while executing saveallcnf, savesmcnf and other tftp downloads to the C:FW and C:CNF and C:RPM directories. During such a time after losing all descriptors, will not be able to telnet to shelf and console access will show the above error. The work around is to do switchcc.

Status Change: Duplicate of CSCec59200

CSCdz64223

Can not delete dangling conn from switch

Symptom: Customer has an incomplete connection which prevents them from using a valuable PVC to provision new traffic.

Conditions: After executing delcon, there was a dangling connection.

Workaround: Move traffic to another PVC until the dangling con can be removed.

Status Change: Duplicate of CSCea33131

CSCea75062

Interface on FRSM-2CT3 failed, root cause cant be determined.

Symptom: Customer reported interface went down and came back up.

The node log only reported:

04/14/2003-13:07:33 07 PAR:Fail    PAR-7-INTFC_OK             
 Interface 5.199 Ok
04/14/2003-13:06:48 07 PAR:Fail    PAR-7-INTFC_FAIL           
 Interface 5.199 Failed

Conditions: This failure caused an outage and the root cause was not determined.

Workaround: No workaround was provided at this time.

Status Change: Closed

CSCec72776

PXM ran out of buffers under trap flood and could not download config to SM

Symptom: CWM cannot sync up with node.

Conditions: Corner case: very heavy event (trap) floods cause the switch to prioritize the data plane and control plane functions suffer as a result.

Workaround: identify the source of the events (traps) and resolve it.

Status Change: Closed

CSCec72860

Node unreachable for 2 mins after PXM switchover

Symptom: Node went unreachable

Conditions: After the Active PXM switched over to standby PXM

Workaround: None available

Status Change: Duplicate of CSCds64653

CSCec72866

Node unreachable for 2-3 mins after PXM in slot 7 reset

Symptom: Node went LMI unreachable

Conditions: after PXM in slot 7 reset

Workaround: None.

Status Change: Closed

CSCec73009

Standby PXM reset spontaneously

Symptom: Standby PXM reset spontaneously

Conditions: None.

Workaround: None.

Status Change: Closed

CSCed39882

PXM core dump. Software reset with RCA

Symptom: PXM switches over and dumps core.

Core error is Software Error Reset.

Conditions: Node has been very unstable due to CSCdz22740. Customer is aware of bug and steps required to avoid and prevent further outages.

One PXM has also been sent for EFA to investigate possible HW issue.

Workaround: None.

Status Change: Duplicate of CSCdz22740

CSCed43109

Receive RAI clears on softswitch

Symptom: RcvRAI Clears when a softswitch is done. No Bulk mode - 1:N redundancy. AUSM-8T1

Conditions: This was reproduced in the Lab as a result of looking for another problem. SW 1.1.34

Workaround: None.

Status Change: Closed

CSCed77760

tDbgOutTask is Blocked on msgQ causes PXM reset tRoot Task

Symptom: PXM1-4-155 Resets after user apparently tried to close the window without exiting out from the telnet session first, dsperr shows:

tRootTask   SYS-1-HANGTASK        00412
Task[tDbgInTask:0xe] is hanging on task delete 0x8223a070

tDbgInTask is trying to delete tDbgOutTask because of the above action. tDbgOutTask is blocked on a msgQ and hence tDbgInTask was not able to delete it.tRootTask reset the PXM cos tDbgInTask was hanging on deletion of the tDbgOutTask.

Conditions: PXM1-4-155 is was in Active state, running 1.1.34 FW

Workaround: None.

Status Change: Duplicate of CSCed22740

CSCed86460

restoreallcnf fails because standby card is taking control from active

Symptom: Customer issues a "restoreallcnf" command, node resets itself (which it is supposed to do) but then the node comes back up on the previously standby card and the restoreallcnf fails. Node should come back up on the previously active card to restore the configurations. Customer is running 1.2.01 and it is a PXM1-4-155 node.

Conditions: Normal conditions. Normal traffic. Customer did go through a downgrade/upgrade procedure. We are still not sure whether downgrade/upgrade procedure that the customer used is related to this or not.

Workaround: Pulling out the standby card from the chassis and then perform restoreallcnf.

Status Change: Closed

CSCee12055

PXM memory depletion

Symptom: Node reporting low DRAM. Some cards are shown in mismatch. One slot is shown as failed per the red table.

Conditions: IMA port bouncing. Everything else operating normal.

Workaround: Execute switchcc to recover memory. Reset cards that are in wrong state.

Status Change: Duplicate of CSCdy59136

CSCee18772

PXM reset due software exception at Vector5 EPC

Symptom: PXM resets due to software exception Vector 5

03/19/2004-19:47:19 07 tSCM        SSI-3-EXCEPTION       00009
 Software Exception: Vector 5  EPC: 0x8004d91c  ADDR: 0xa7f88ccf.

Conditions: Found on MGX 8250 running 1.2.02 with no service modules installed.

Workaround: Root cause unknown but both instances result in the PXM resetting and recovering back into Standby successfully.

Status Change: Duplicate of CSCee40233


Compatibility Notes

MGX 8230, MGX 8250, and MGX 8850 (PXM1) Software Certification with Other Products

Table 10 lists how MGX software version 1.2.23 interoperates with other products.

Table 10 Software That was Certified with MGX Release 1.2.23 

Switch or Component
Certified Software Version

MGX 8230, MGX 8250, and MGX 8850 (PXM1)

MGX 1.2.23

MGX 8850 (PXM45), MGX 8850 (PXM1E), and MGX 8950

MGX 4.0.10

MGX 3.0.23

MGX 3.0.20

MGX 2.1.81

BPX Switch Software:

9.4 Release, 9.4.10

9.3 Release, 9.3.36, 9.3.47

9.2 Release, Switch Software 9.2.43

BPX SES Shelf:

SES 4.0.10

SES 3.0.23

SES 3.0.20

SES 1.1.75

Cisco WAN Manager

CWM 12.0.00 Patch 1.1

MGX 8220 Shelf:

MGX 8220 4.1.12

MGX 8220 5.0.19

VISM

VISM Release 3.1.2

VISM Release 2.2.1

VISM Release 1.5.08


Boot File Names and Sizes

Table 11 displays the boot file names and sizes for this release.

Table 11 Boot File Names and Size

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.06.fw

468388

pxm_bkup_1.2.23.fw

1352068

rpm-boot-mz.122-15.T5

3202984


MGX 8250 and MGX 8850 (PXM1) Firmware Compatibility

The firmware compatibility matrix for this release is presented in Table 12.

Table 12 MGX 8250 Switch and MGX 8850 (PXM1) Switch Firmware Compatibility Matrix 

PCB Description
CW2000 Name
Latest F/W
File Name
File Size
(in bytes)

PXM1

PXM-1

1.2.23

pxm_1.2.23.fw

2622728

PXM1-2-T3E3

PXM1-2T3E3

1.2.23

pxm_1.2.23.fw

2622728

PXM1-4-155

PXM1-4OC3

1.2.23

pxm_1.2.23.fw

2622728

PXM1-1-622

PXM1-OC12

1.2.23

pxm_1.2.23.fw

2622728

MGX-SRM-3T3/B

SRM-3T3

MGX-SRM-3T3/C

SRM-3T3

MGX-SRM-E

SRM-E

MGX-AUSM-8E1/B

AUSMB-8E1

10.2.21

ausm_8t1e1_10.2.21.fw

1389832

MGX-AUSM-8T1/B

AUSMB-8T1

10.2.21

ausm_8t1e1_10.2.21.fw

1389832

AX-CESM-8E1

CESM-8E1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

AX-CESM-8T1

CESM-8T1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

MGX-CESM-8T1/B

CESM-8T1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

MGX-CESM-T3

CESM-T3

10.2.21

cesm_t3e3_10.2.21.fw

640992

MGX-CESM-E3

CESM-E3

10.2.21

cesm_t3e3_10.2.21.fw

640992

AX-FRSM-8E1/E1-C

FRSM-8E1

10.2.21

frsm_8t1e1_10.2.21.fw

897464

AX-FRSM-8T1/T1-C

FRSM-8T1

10.2.21

frsm_8t1e1_10.2.21.fw

897464

MGX-FRSM-HS2/B

FRSM-HS2/B

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-HS2

FRSM-HS2

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2CT3

FRSM-2CT3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2T3E3

FRSM-2T3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2T3E3

FRSM-2E3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-HS1/B

FRSM-HS1/B

10.2.21

frsm_hs1_10.2.21.fw

775144

MGX-RPM-128M/B

RPM

12.2(15)T5

rpm-js-mz.122-15.T5(IOS)

9980112

MGX-RPM-PR

RPM

12.2(15)T5

rpm-js-mz.122-15.T5 (IOS)

9980112


MGX 8230 Firmware Compatibility

The MGX 8230 firmware compatibility matrix for this release is presented in Table 13.

Table 13 MGX 8230 Firmware Compatibility Matrix 

PCB Description
CW2000 Name
Latest F/W
File Name
File Size
(in bytes)

PXM1

PXM-1

1.2.23

pxm_sc_1.2.23.fw

2619172

PXM1-2-T3E3

PXM1-2T3E3

1.2.23

pxm_sc_1.2.23.fw

2619172

PXM1-4-155

PXM1-4OC3

1.2.23

pxm_sc_1.2.23.fw

2619172

PXM1-1-622

PXM1-OC12

1.2.23

pxm_sc_1.2.23.fw

2619172

MGX-SRM-3T3/B

SRM-3T3

MGX-SRM-3T3/C

SRM-3T3

MGX-SRM-E

SRM-E

MGX-AUSM-8E1/B

AUSMB-8E1

10.2.21

ausm_8t1e1_10.2.21.fw

1389832

MGX-AUSM-8T1/B

AUSMB-8T1

10.2.21

ausm_8t1e1_10.2.21.fw

1389832

AX-CESM-8E1

CESM-8E1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

AX-CESM-8T1

CESM-8T1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

MGX-CESM-8T1/B

CESM-8T1

10.2.21

cesm_8t1e1_10.2.21.fw

736592

MGX-CESM-T3

CESM-T3

10.2.21

cesm_t3e3_10.2.21.fw

640992

MGX-CESM-E3

CESM-E3

10.2.21

cesm_t3e3_10.2.21.fw

640992

AX-FRSM-8E1/E1-C

FRSM-8E1

10.2.21

frsm_8t1e1_10.2.21.fw

897464

AX-FRSM-8T1/T1-C

FRSM-8T1

10.2.21

frsm_8t1e1_10.2.21.fw

897464

MGX-FRSM-HS2/B

FRSM-HS2/B

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-HS2

FRSM-HS2

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2CT3

FRSM-2CT3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2T3E3

FRSM-2T3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-2T3E3

FRSM-2E3

10.2.21

frsm_vhs_10.2.21.fw

1026100

MGX-FRSM-HS1/B

FRSM-HS1/B

10.2.21

frsm_hs1_10.2.21.fw

775144

MGX-RPM-128M/B

RPM

12.2(15)T5

rpm-js-mz.122-15.T5 (IOS)

9980112

MGX-RPM-PR

RPM

12.2(15)T5

rpm-js-mz.122-15.T5 (IOS)

9980112


Comparison Matrix

The multiservice gateway comparison matrix (Table 14) is designed to identify capabilities supported in the MGX 8220, MGX 8230, MGX 8250, and MGX 8850 (PXM1) platforms.

Table 14 MGX 8220, MGX 8230, MGX 8250, and MGX 8850 Comparison Matrix 

Feature
MGX 82201
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

Yes

Yes

 
Automatic Protection Switching
(APS 1+1)
8220
8230
8250
8850

APS on PXM-1

No

Yes

Yes

Yes

APS on SRM-3T3/B

No

Yes

Yes

Yes

APS on SRM-3T3/C

No

Yes

Yes

Yes

APS on SRM-E

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

 
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

MGX-FRSM-HS2/B

No

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-TE1

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

MGX-CESM-8T1/B

Yes

Yes

Yes

Yes

AX-SRM-T1E1/B

Yes

No

No

No

AX-SRM-3T3

Yes

No

No

No

MGX-SRM-3T3/B

Yes

Yes

Yes

Yes

MGX-SRM-3T3/C

Yes

Yes

Yes

Yes

MGX-SRM-E

No

Yes

Yes

Yes

MGX-VISM-8T1

No

Yes

Yes

Yes

MGX-VISM-8E1

No

Yes

Yes

Yes

MGX-VISM-PR-8T1

No

Yes

Yes

Yes

MGX-VISM-PR-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

 
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-12IN1-8S

No

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

PXM-UI

No

Yes

Yes

Yes

PXM-UI-S3

No

Yes

Yes

Yes

MGX-MMF-4-155/B

No

Yes

Yes

Yes

OC3/STM1

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

1 MGX 8220 is no longer orderable.


RPM Compatibility Matrix

Table 15 presents a matrix of which RPM releases are compatible with which CWM releases.


Note For version 12.2(15)T, refer to:

http://www.cisco.com/cgi-bin/Software/Iosplanner/Planner-tool/printsa.pl?geget_crypto=&data_from=&hardware_name=&software_name=&release_name=12.2.15T&majorRel=12.2&state=:RL&type=Early%20Deployment&file=12.2.15T.c.html.


Table 15 RPM and CWM Compatibility Matrix

MGX SW version
1.1.34
1.1.42
1.2.00
1.2.02
1.2.11
1.2.13
1.2.23

IOS Version

12.2(2)T2

12.2(4)T1

12.2(4)T1

12.2(8)T11

12.2(11)T1

12.2(11)T2

12.2(15)T5

CWM

10.4.01
Patch 1

10.4.10 Patch 2

10.5.10

10.5.10
Patch 1

11.0.10

11.0.10
Patch 1

12.0.00
Patch 1.1

1 MGX 1.2.02 has also been certified with IOS 12.2(4)T3.


MGX 8850 (PXM1), MGX 8250, and MGX 8230 Release 1.2.23 Hardware

Table 16 shows the front card and back card compatibility for the hardware supported in this release. The table lists the card model/ name, part numbers, the minimum version and the minimum revisions of each card supported in Release 1.2.23. Note that there may be more than one 800 level part numbers for the same front cards. The minimum version is identified by the last 2 digits of the 800 level numbers.

Table 16 Hardware Compatibility Matrix 

Front Cards
Part Number/
Min. Version
Rev.
Back Cards
Part Number/
Min. Version
Rev.

PXM1

800-05084-02

800-05760-01

800-07888-01

A0

A0

PXM-UI

PXM-UI-S3

800-03688-01

800-05787-01

A0

A0

PXM1-4-155

800-05086-02

800-05762-01

800-06229-02

A0

A0

A0

PXM-UI

PXM-UI-S3

MGX-MMF-4-155/B

MGX-SMFIR-4-155/B

MGX-SMFLR-4-155/B

800-03688-01

800-05787-01

800-05053-01

800-05351-01

800-05352-01

A0

A0

A0

A0

A0

PXM1-1-622

800-05085-02

800-05763-01

800-06228-02

A0

A0

A0

PXM-UI

PXM-UI-S3

MGX-SMFIR-1-622/B

MGX-SMFLR-1-622/B

800-03688-01

800-05787-01

800-05379-01

800-05381-01

A0

A0

A0

A0

PXM1-2-T3E3

800-05087-02

800-05602-01

800-06230-02

A0

A0

A0

PXM-UI

PXM-UI-S3

MGX-BNC-2E3

MGX-BNC-2E3A

MGX-BNC-2T3

800-03688-01

800-05787-01

800-04056-02

800-04743-02

800-04057-02

A0

A0

A0

A0

A0

MGX-SRM-3T3/B

800-04092-01

E0

MGX-BNC-3T3-M

800-03148-02

A0

MGX-SRM-3T3/C

800-05648-01

A0

MGX-BNC-3T3-M

800-03148-02

A0

MGX-SRME

800-14224-02

A0

MGX-SMFIR-1-155

MGX-STM1-EL-1

800-14460-02

800-14479-02

A0

A0

MGX-AUSM-8E1/B

800-04810-01

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

MGX-AUSM-8T1/B

800-04809-01

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

AX-CESM-8E1

800-02751-02

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

AX-CESM-8T1

800-02750-02

A0

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

MGX-CESM-8T1/B

800-08613-02

A0

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

MGX-CESM-T3E3

800-03864-02

A0

MGX-BNC-2E3

MGX-BNC-2E3A

MGX-BNC-2T3

800-04056-02

800-04743-02

800-04057-02

A0

A0

A0

AX-FRSM-8E1

800-02438-04

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

AX-FRSM-8E1-C

800-02462-04

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

AX-FRSM-8T1

800-02437-04

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

AX-FRSM-8T1-C

800-02461-04

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

MGX-FRSM-2CT3

800-02910-04

800-06335-01

A0

A0

MGX-BNC-2T3

800-04057-02

A0

MGX-FRSM-2T3E3

800-02911-03

A0

MGX-BNC-2E3

MGX-BNC-2E3A

MGX-BNC-2T3

800-04056-02

800-04743-02

800-04057-02

A0

A0

A0

MGX-FRSM-HS1/B

800-05129-01

A0

MGX-12IN1-4S

MGX-SCSI2-2HSSI/B

800-04981-01

800-05463-02
800-05501-01

A0

A0
A0

MGX-FRSM-HS2

800-02909-03

A0

MGX-SCSI2-2HSSI/B

800-05463-02
800-05501-01

A0
A0

MGX-FRSM-HS2/B

800-17066-01

A0

MGX-12IN1-8S

800-18302-01

A0

MGX-RPM-128M/B

800-05743-01

A0

MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E

MGX-MMF-FDDI

MGX-MMF-FDDI/FD

MGX-SMF-FDDI

MGX-SMF-FDDI/FD

800-02735-02

800-03202-02

800-02737-02

800-02857-01

800-03820-01

800-02736-01

800-03822-01

A0

A0

A0

A0

A0

A0

A0

MGX-RPM-PR-256

800-07178-02

A0

MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E/B

800-02735-02

800-03202-02

800-12134-01

A0

A0

A0

MGX-RPM-PR-512

800-07656-02

A0

MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E/B

800-02735-02

800-03202-02

800-12134-01

A0

A0

A0

MGX-VISM-8E1

800-04398-01

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

MGX-VISM-8T1

800-04399-01

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0

MGX-VISM-PR-8E1

800-07991-02

A0

AX-SMB-8E1

AX-R-SMB-8E1

AX-RJ48-8E1

AX-R-RJ48-8E1

MGX-RJ48-8E1

800-02287-01

800-02410-01

800-02408-01

800-02409-01

800-19310-01

A0

A0

A0

A0

A0

MGX-VISM-PR-8T1

800-07990-02

A0

AX-RJ48-8T1

AX-R-RJ48-8T1

800-02286-01

800-02288-01

A0

A0


]

Special Installation and Upgrade Requirements

Existing customers should use the upgrade procedure Service Module Upgrades to upgrade. A graceful upgrade from any release previous to the current release is supported. For new customers, the image will be pre-installed 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 (for example, MGX 1.1.3x, 1.1.4x, 1.2.20, 1.2.21, or 1.2.22 to MGX 1.2.23), 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

When upgrading from any release prior to Release 1.1.32, under certain conditions with the FRSM 2 CT3, a script must be ran in order to properly upgrade the software. 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 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.

Upgrade Procedure for Non-Redundant PXM

Upgrading a switch with non-redundant PXMs is an ungraceful upgrade. An ungraceful upgrade from any release previous to the current release is supported (for example, MGX 1.1.3x, 1.1.4x, 1.2.20, 1.2.21, or 1.2.22 to MGX 1.2.23).


Step 1 Save your current configuration.

saveallcnf

Step 2 Get the filename by listing the CNF directory:

node-prompt> ll "C:/CNF"
size          date           time       name
--------      ------         ------     --------
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      
In the file system : 
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> bin
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> bin
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
tftp> quit

Step 5 Download the release to upgrade PXM runtime image to the PXM. For example:

tftp> <node_name or IP address> 
tftp> bin 
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
tftp> quit 


Step 6 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Enter the TFTP put command:

tftp <node_name or IP address> 
tftp> bin 
tftp> put ComMat.dat 
tftp> quit 

Step 7 On the PXM type the following when the transfer is done:

PXM.a> copy ComMat.dat /FW/ComMat.dat 

Step 8 Enter install bt <new_rel>.

Step 9 Enter install <new_rel>. At the end of the display, enter yes.

PXM.a> install <new_rel>
redundancy is not available
the other card is not available
you are not in redundant mode,
do you want to try an ungraceful upgrade
(yes or no)?yes

Upgrade Procedure for Redundant PXMs

This section applies to upgrades from 1.1.34 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.



Step 1 Save your current configuration.

saveallcnf

Step 2 Get the filename by listing the CNF directory:

        node-prompt> ll "C:/CNF"
          size          date       time       name
        --------       ------     ------    --------
             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      
        In the file system : 
            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> bin
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> bin
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
tftp> quit

Step 6 From the workstation, download the PXM FW.

unix-prompt> tftp <pxm.ip.address>
tftp> bin
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:

Program length = 1982672
Calculated checksum = 0xd9779bc6 stored checksum = 0xd9779bc6
Fw checksum passed


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. Enter the TFTP put command:

unix-prompt> tftp <node_name or IP address> 
tftp> bin 
tftp> put ComMat.dat 
tftp> quit 

Step 8 After the transfer is done, type the following on the PXM:

PXM.a> copy ComMat.dat /FW/ComMat.dat

Step 9 Enter the command install bt <new_rel>.

Step 10 Enter the command install <new_rel>.

Step 11 After the Standby card is reset and successfully enters the hold state, on the Active PXM, enter the command newrev <new_rel>.

The Active card will be reset and go to hold state.

After the newrev, enter the command dspcd to show the firmware revision on the new, active PXM.


Caution If at this stage (after newrev) the upgrade needs to be aborted, follow the instructions under "Instructions to Abort PXM Upgrade."

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, enter 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.

Aborting an Upgrade from Release 1.1.3x and Above

If the upgrade needs to be aborted for any reason during the upgrade process from release 1.1.3x and above, follow these instructions.


Step 1 Execute abort <release no>

PXM.a> abort <release no> 

Aborting an Upgrade from Release 1.1.2x

If the upgrade needs to be aborted for any reason during the upgrade process from release 1.1.2x, follow these instructions.


Step 1 If the abort is required before the newrev command is entered, skip to Step 8.

Step 2 Enter the following commands if the upgrade process is past the newrev stage.

Step 3 On the Active PXM, enter shellConn

Step 4 Enter smCardMibVer = 21

Step 5 Enter saveDBToArchive <PXM SlotNo>, 0

Step 6 Enter uploadBram <PXM SlotNo>, <PXM SlotNo>

The <PXM SlotNo> should be 7 for the MGX 8850 (PXM1) 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 MGX 8230 switch (even if the Active PXM is in slot 2 use slot 1).

The example that follows is for the MGX 8850.

PXM.a > shellConn
-> smCardMibVer=21
-> saveDBToArchive 7, 0
-> uploadBram 7, 7

Step 7 If RPM cards also are on this node, perform the following for each RPM card:

Inside shellConn on Active PXM, enter:

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:
-> d &arcMem+36
d &arcMem+36
8051cb90:            8702 bad8 0000 0000 0000 0000   *      ..........*
8051cba0:  0000 0000 0000 0000 0000 0000 0000 0000
-> rmSlotArchFileSave 9,0x8702bad8 

Step 8 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> bin 
tftp> put <backup boot> POPEYE@SM_1_0.BT
tftp> quit

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> bin
tftp> put <FW file> POPEYE@SM_1_0.FW
tftp> quit 

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> bin 
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: node1 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 node1 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 > 
tftp> bin 
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 #>
tftp> chkflash

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 Boot/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 Enter the following command to install the service module boot file:

install bt sm <slot> <version>

where <slot> is the service module that is being upgraded

and <version> is the service module image on the disk.

Step 4 For graceful upgrades, a secondary card should be backing up the service module that needs to be upgraded. Configure the redundancy and enter the following 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.


Historical Information from the 1.2.x Baseline

Features Introduced in Release 1.2.20

AUSM CAC Based on SCR in VBR

On MGX 8250/8230 platforms, CAC for VBR connections was based on PCR only for AUSM and PXM1 cards. This feature provides a mechanism to the users to choose the CAC based on SCR or PCR for VBR connections.

As part of this feature an option is provided to the customer to select the CAC feature per card. Once the option for SCR based CAC is chosen, any VBR service type connection addition with CAC enabled checks for Connection Admission using the SCR rate limit. If the connection does not pass the CAC, addition will fail.

The default value for CAC will be PCR and will work exactly as it does today in the current firmware. Therefore, existing customers who are currently using CAC based on PCR will not have to execute the new CLI command.

A new CLI command has been introduced as part of this feature:

cnfcacparm <option value>

option value: 1 / 2

1: PCR based. This is the default value.

2: SCR based. This is the new CAC algorithm

To display the configured CAC option:

dspcacparm

Features Introduced in Release 1.2.13

In addition to the following new features, Release 1.2.13 supports all new features introduced in the Release 1.2.x baseline.

Additional PXM1 Stats and NBSM Stats for AUSM and FRSM

Statistics Collection is used to monitor the traffic conditions on the MGX 8250 and MGX 8230 nodes, Statistics are collected from every Service Module card at the user specified interval. The Statistical Collection Manager is a CWM feature. For this release, we are adding statistics for the FRSM and AUSM service modules, specifically, the statistics on the MGX-FRSM-VHS, MGX-FRSM-8T1E1 and MGX-AUSM-8 T1E1 service modules, as well as the PXM1.

For more information, refer to the latest CWM release notes.

Command to Terminate a Telnet Session

The delsesn command lets you terminate one or more user-sessions. To see the number of the each active session, use the dspsesn command. Termination takes place immediately upon command execution. Before it proceeds, the CLI warns you that the command is destructive. If you proceed with the deletion, the user whose session is being deleted receives the message, "Forced Logout By <userid> !!!!!!!!!!!," where userid is the user running the delsesn command. Note that you can delete any user-session command with this command. The command syntax is the following.

delsesn <sesn no> [sesn no>] [sesn no>] ...

where

sesn no designates the number of the session in the range 0-15. At least one session number is mandatory, and all others up to a total of 15 are optional. The dspsesn command can provide the user-session numbers.

For example, use the dspsesn command to determine the existing user-sessions. Delete session 2 (user "david9"), then repeat the dspsesn command. Note that the dspsesn output provides a form of the user-session number that delsesn requires: "Session 2."

M8850_NY.7.PXM.a > M8850_NY.7.PXM.a > dspsesn

    Port        Slot      Idle       UserId       From
    -------------------------------------------------------------
    telnet.01 *    7     0:00:00     david        10.19.238.35
    telnet.02      7     0:00:18     david9       10.19.238.35

M8850_NY.7.PXM.a > M8850_NY.7.PXM.a > dspsesn

-----------------------------------------
 > Session 0 (console): 
Waiting for login...

-----------------------------------------
*> Session 1 (telnet): 
Executing command: dspsesn

user name:         david
access level:      SERVICE_GP
slot:              7
slotFallback:      1
From:              10.19.238.35

-----------------------------------------
 > Session 2 (telnet): 
Waiting for user input...

user name:         david9
access level:      GROUP1
slot:              7

slotFallback:      7
From:              10.19.238.35

M8850_NY.7.PXM.a > delsesn 2
WARNING! delsesn is a destructive command it will 
non-gracefully delete sessions selected by you 
Do you wish to proceed ? [y/n] y

M8850_NY.7.PXM.a > dspsesn

-----------------------------------------
 > Session 0 (console): 
Waiting for login...

-----------------------------------------
*> Session 1 (telnet): 
Executing command: dspsesn

user name:         david
access level:      SERVICE_GP
slot:              7
slotFallback:      1
From:              10.19.238.35

Features Introduced in Release 1.2.11

In addition to the following new features, Release 1.2.11 supports all new features introduced in the Release 1.2.x baseline.

RPM Automatic Cellbus Double Clocking

When enabled, this feature will automatically double the Cellbus clock timing when two adjacent RPMs are inserted in the same Cellbus. The doubling of the Cellbus clock provides better traffic management when both RPM clocks rates are set at 42 MHz. Previously, the setting of the Cellbus clock was a manual process.

Enhanced Alarm Filtering

Currently, MGX switches report an integrated shelf alarm to the CWM via the Shelf Integrated alarm trap and MIB. This feature will enhance the switch to report an extra filtered integrated shelf alarm state in the trap and MIB to the CWM and all NMS systems.

The filtered integrated shelf alarm will ignore all lines, ports, connections and feeder alarms. CWM will provide the option to configure the network on a per user basis to display the real integrated shelf alarm or the filtered integrated shelf alarm.

Features Introduced in Release 1.2.10

In addition to the following new features, Release 1.2.10 supports all new features introduced in the Release 1.2.x baseline.

AUSM-8T1E1 Egress Channel Counters

New AUSM egress counters for channels and ports have been added to monitor traffic statistics. The new statistics are configured through the Statistics Collection Manager (SCM) in the CWM and require no new CLI commands. You can, however, verify the statistics against the traffic using the dspchancnt, dspsarcnt and dspportcnt CLI commands.

For more information, refer to the CWM Release 11 documentation.

PXM-UI-S3 Secondary BITS Clocking

In this release, the PXM-UI-S3 back card, which provides Stratum level 3 clock source inputs, has been enhanced to accept two external BITS clock inputs. A new interface, 7.36, has been added to support one more external clock input. Thus, interface 7.36 now refers to the second BITS clock input of the PXM-UI-S3 back card. The properties and use of this newly added interface is exactly the same as that of interface 7.35, which refers to the first BITS clock input of the PXM-UI-S3 back card. The second BITS clock source can be added as primary, secondary or tertiary clock source, which is the same for any other clock interface.

VISM-PR Front Cards

VISM Release 3.0 introduces the new VISM-PR front cards. The new VISM-PR-8E1 and VISM-PR-8T1 cards work in the MGX 8230, MGX 8250 and MGX 8850 Release 1 switches, in combination with the PXM1 Processor Module card. The VISM-PR cards support 144 channels when used with the G.723.1 codec, whereas the current VISM cards support 64 channels with the G.723.1 codec.


Note The VISM-PR-8E1 and VISM-PR-8T1 cards use the same back cards as the current VISM front cards.


For more information, refer to the Release Notes for Cisco Voice Interworking Service Module Release 3.0(0) and the Cisco VISM Installation and Configuration Guide, Release 3.0.

Features Introduced in Release 1.2.02

Release 1.2.02 supports all new features introduced in the Release 1.2.0x baseline. The following is a new feature for RPM implementations using IOS Release 12.2(8)T1.

Configuring the Cellbus Clock (CBC) Rate

When two adjacent RPM cards are on the same cell bus, that is, occupy adjacent slots, the cellbus clock (CBC) rate should be set to 42MHz. If, for any reason, one of the adjacent RPMs goes to Failed or Empty state, the CBC must be reconfigured to 21MHz on the active, live RPM card, for Traffic Shaping to work correctly. For more information, refer to the RPM release notes.

Features Introduced in Release 1.2.01

Release 1.2.01 is a feature release. Table 17 contains a short description of the new features that are available with Release 1.2.01.


Note Due to CSCdx06855, MGX 1.2.01 is no longer generally available and has been deferred. This DDTS has been resolved in MGX 1.2.02.


Table 17 Features Released in 1.2.01

Feature
Comment

Standard ABR on FRSM-VHS Modules.

This feature implements standard TM 4.0 ABR service on the FRSM-VHS card.

APS Support on SRM-E

The enhanced SRM-E Service Redundancy Module, which was introduced in Release 1.2.00, now provides GR.253 and ITU Annex-A and Annex-B APS 1+1 support.


Standard ABR on FRSM-VHS Modules

The feature implements TM 4.0 ABR service on the FRSM VHS cards which include FRSM-2CT3, FRSM-2T3E3, FRSM-HS2 and FRSM-HS2/B. The current FRSM supports a pre-standard version of congestion control- foresight. 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. The scope involves to including all applicable modes of behavior Source, Destination or Switch. Only relevant modes need be considered. Connections with standard ABR parameter will be mapped to appropriate queues that also will co-exist with foresight connection types. For more information, refer to ForeSight and Standard ABR Coexistence Guidelines.

This feature will be implemented via appropriate MIBS and CLI. This feature is supported by CWM 10.5.10 patch 1. There will be one common license for foresight and standard ABR on FRSM. This is a billable feature. Standard ABR fulfills the standards compliance part of TM 4.0.

APS Support on SRM-E

The enhanced SRM-E Service Redundancy Module now provides GR.253 and ITU Annex-A and Annex-B APS 1+1 support. The SRM-E supports a new one-port OC3/STM1 back card, BERT, 1:N redundancy for the 8 port service modules and both T1 and E1 bulk distribution for the 8 port service modules. For more information on SRM-E, refer to SRM-E and New and Changed Commands in the 1.2.x Baseline.

For intercard APS to operate properly on the MGX 8850 and MGX 8250, an APS connector must be installed between the two cards. For more information on the APS connector and how to install it, see the Cisco MGX 8850 Routing Switch Hardware Installation Guide.


Note The MGX 8230 does not require the APS connector.


Features Introduced in Release 1.2.00

Release 1.2.00 is a feature release. Table 18 contains a short description of the features which are available with Release 1.2.00.

Table 18 Features Available in Release 1.2.00

Feature
Comment

FRSM-HS2/B.

In addition to the current HSSI interface support, the new service module supports V.35 and X.21 Frame Relay interfaces.

SRM-E

Service Redundancy Module is an enhanced version of the current SRM-3T3 card, supporting a new one-port OC3/STM1 back card. The new card supports BERT, 1:N redundancy for the 8 port service modules and both T1 and E1 bulk distribution for the 8 port service modules. APS support will be available in a future release.

ITU APS Annex-A, All Configurations Supported on PXM1.

This feature was introduced in Release 1.1.40 with some configurations supported; now all are supported. Compatible with CWM 10.5 and higher.

CESM 8T1 Model B

This feature eliminates problem in DS0 throughput reduction when CESM channels are configured in CAS mode (not applicable for E1 lines).

PXM-UI-S3,

This feature provides support for Stratum-3 clocking. This card was first supported in Release 1.1.31. Release 1.1.31 was compatible with CWM 10.3. The upgrade to Release 1.2.00 provides important fixes to this feature.


FRSM-HS2/B

The FRSM-HS2/B service module supports v.35 and x.21 frame relay interfaces in addition to the current HSSI interface. A new 8 port back card 12IN1-8S is introduced. The new front card supports the current HSSI back card and the new 12IN1-8S back card. All the current FRSM-HS2 features are supported in addition to the FRSM-HS1/B features. Each interface in the 12IN1-8S can be individually configured as x.21 or v.35 interface. The new service module supports a maximum of 4000 connections with the 12IN1-8S back card and 2000 connections with the HSSI back card when no LMI is configured. When LMI is configured, the maximum number of connections per port for strataLMI port is 560 and Annex A/D UNI/NNI port is 898.

The FRSM-HS2/B supports both DCE and DTE modes with line rates between 48Kbps to 51.84 Mbps for HSSI interface and 48Kbps to 8.192 Mbps for v.35/x.21 interface. In FRSM-HS2B, for DTE interfaces the clock frequency threshold % is introduced and is configurable (1 - 5)% with a default value of 3%. The new front card and back card is supported in CWM 10.5.10.


Warning Do not configure an interface to a DTE mode when a physical loopback plug is plugged in. This will cause the line to go in and out of alarm, and cause software errors in the PXM. Use the command cnfln to configure the line as DCE to recover from this situation. For further information refer to bug CSCdv79470.


A comparison of the FRSM-HS1/B, FRSM-HS2, and FRSM-HS2/B is shown in Table 19.

Table 19 Comparison of FRSM Modules 

Quality
FRSM-HS1/B
FRSM-HS2
FRSM-HS2/B

back card supported

12IN1-4S

HSSI

HSSI, 12IN1-8S

port count

4

2

2 with HSSI

8 with 12IN1-8S

maximum line rate

8 Mbps

52 Mbps

52 Mbps with HSSI

8 Mbps with 12IN1-8S

individually configurable interface type

No

No

No with HSSI

Yes with 12IN1-8S

DTE clock monitoring threshold

Available

maximum number of connections

200

2000

2000 with HSSI

4000 with 12IN18-S

redundancy support

No

1:1

1:1 with HSSI

None with 12IN1-8S


Table 20 lists the cables necessary for card performance.

Table 20 Cables Supported for HSSI 

DCE
DTE
Cable

FRSM-HS2/B

Cisco router

St. Cable 72-0710-01

FRSM-HS2/B

Non-Cisco standard DTE

St. Cable 72-0710-01

Cisco router

FRSM-HS2/B

St. Cable 72-0710-01

Non-Cisco standard DCE

FRSM-HS2/B

Cross Cable 72-1265-01

FRSM-HS2/B

FRSM-HS2/B

Cross Cable 72-1265-01


SRM-E

The new Service Redundancy Module is an enhanced version of the current SRM-3T3 card. The new card supports a one-port OC3/STM1 back card or functions without a back card. See Table 21.

Table 21 SRM-E Features Supported With and Without Back Cards

Features Supported Without a Back Card
Features Supported With a Back Card

BERT

Bulk Distribution

1:N redundancy

BERT

--

1:N redundancy


The new card supports BERT, 1:N redundancy for the 8 port service modules and both T1 and E1 bulk distribution for the 8 port service modules. Support for both GR-253 and ITU- Annex A and B APS 1+1 will be provided in a future release.

The new front card will function without the back card for BERT and 1:N redundancy features. CWM and CiscoView will support the new front and back card.

You can have either 0, 2 or 4 SRM's with redundant processors and 0, 1 or 2 with non-redundant processors. The MGX 8250 or MGX 8850 shelf has two bays while the MGX 8230 has only one bay. Each bay of the MGX 8x50 requires its own SRM-E card along with its respective back card. For full redundancy for the shelf, you need 4 SRM-Es and their respective back cards for MGX 8850 or MGX 8250 switch (2 SRM-Es for MGX 8230). Since the SRM-E is part of the core card set, if redundancy is required for the PXM, then redundancy also should be provided for the SRM-E.

SRM-E cards do not require any firmware to be downloaded to them. They are controlled by platform software running on the PXM. When a switch-over occurs from active PXM to standby PXM, the corresponding SRM-E cards (as part of the core card set) will also switch.

The interfaces available (through the appropriate back cards below) are:

OC3 optical

STS3 electrical

STM1 optical

STM1 electrical

The following cards are supported on both MGX 8850 or MGX 8250 switch and the MGX 8230 switch:

SMFIR: Single Mode Intermediate Range Fiber

STM1-EL-1: Synchronous Transport Module level 1

Table 22 lists SRM-E limitations and limits on MGX switches, andTable 23 lists SRM-E LED descriptions.

Table 22 SRM-E Limitations and Limits for MGX Switches 

Limitations
Limits

Physical Interfaces

Data Communication Channel (DCC) bytes in the Sonet/SDH overhead bytes are not supported.

Byte-synchronous mapping will be implemented only for T1. Support for E1 will be implemented in a subsequent phase only if required.

Bulk-mode Distribution

Service module lines should be mapped to bulk-distributed channels on an all-or-none basis, i.e., a service module should get all of its lines either from its back card or from the distribution bus but not both.

BERT

When BERT is active, regular user traffic cannot flow on the port/line being tested.

Only one BERT session per SRME can be active at any one time.

You must stop an ongoing BERT operation to configure a different pattern.

Far end loopbacks and V.54 polynomial loopbacks are not verified (they are always reported to have succeeded).

If BERT is in progress, it will be stopped (and not resumed) if core card switch-over takes place.

If BERT is in progress, it will be stopped (and not resumed) if APS switch-over is required.

Only redundancy with 2 backcards is supported.

Bulk-mode distribution and redundancy

A maximum of 84 T1 lines and 63 E1 lines can be distributed. Note that 12 slots are available in MGX 8x50 for distribution with a capacity to support 96 T1/E1 lines if 8 line service modules are used.

On MGX 8x50, SRME in a given bay can distribute only to service modules in that bay.

Only one set of service modules can be covered for redundancy in non-bulk mode using redundancy bus. (Multiple sets of service modules can be covered for redundancy in bulk mode)

A redundancy group can not span both bays of MGX 8x50.

Non-bulk mode redundancy

Multiple redundancy groups can be defined but only one redundancy group in each half of the shelf can be using the redundancy bus at any time.

BERT

· The BERT functionality described in this document is for use with the SRME card. The following Service Modules are supported:

FRSM-8T1/E1, AUSM-8T1/E1, CESM-8T1/E1, VISM-8T1/E1, FRSM-2CT3

PN127 patterns are not supported because SRME can only generate the PN127 patterns and the detection is left to the service modules, which can not currently detect the PN127 patterns.

BERT support in the service module is necessary. Service module must support specific services such as verify the existence of a port/line, switch the physical lines to the BERT bus etc.

Automatic Protection Switching

APS will be supported in a future release.

 

Table 23 SRM-E LED Descriptions 

LED
State
Red
Yellow
Green
Off

ACT

Card State

N/A

N/A

Card is active and ready

Card is not yet ready

STDBY

Card State

N/A

Card is in standby mode or a mismatch occurred for active card

N/A

Card is not in standby mode or a mismatch did not occur for the active card

FAIL

Card State

Indicates a major failure with the card

N/A

N/A

Card is working

1:N RED

Card State

N/A

N/A

1:N on-bulk mode redundancy is in force

1:N on-bulk mode redundancy is not in force

BERT

Card State

N/A

N/A

BERT is in progress

BERT is not in progress

Line LED(s)

Line State

Service affecting alarms (LOS, LOF, LOP, AIS etc.)

Non-service affecting alarms (RDI)

Normal operation

Line is not connected


ITU APS Annex-A, All Configurations Supported on PXM1

In the previous MGX1 release (1.1.40), limited ITU-APS Annex-A configuration was validated and made available in MGX 8230, 8250 and 8850 with support for a 1+1 bidirectional non-revertive configuration. In Release 1.2.00, the remaining configurations are supported (see Table 24).

Table 24 Configurations Supported in Release 1.2.00

Features
Limitations

Software

Supported configurations for OC3/STM1 (SMFIR) interface and OC12/STM4 (SMFLR and MMF) interface are:

Bi-directional revertive

Bi-directional non-revertive

Unidirectional revertive

Unidirectional non-revertive

Hardware

There is no support for intracard APS configuration.

Firmware

Interoperability between 1+1 unidirectional and 1+1 bidirectional is not supported.


CESM 8T1 Model B

CESM-8T1 and CESM-8E1 cards provide TDM circuit emulation capabilities over ATM networks, according to ATM forum CES-IS standards.

During field testing, it was found that in the case of CESM-8T1 cards (and not applicable for CESM-8E1 cards), when a CESM channel was configured in CAS mode, the first byte of an AAL1 structure may not be aligned to the first byte of T1 physical level multiframe (SF/ESF). This causes the effective DS0 throughput to reduce from 62.67 Kbps to 60 Kbps. This throughput reduction causes bit errors when the CESM-8T1 is used in certain kind of applications; for example, during transfers of modem calls.

Both hardware and firmware changes were required to eliminate this anomaly. The hardware changes are implemented as CESM-8T1/B revision of the hardware with a minimum Firmware Release 1.2.00. No earlier versions of firmware are supported. The model "B" does not show up via CLI on the PXM or via CWM. However, if the command dspcd is executed from the CESM Model B, it will display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards. The CESM8T1/B card also is identified by a new face plate on which the card name is suffixed with a "B."

Model A and Model B card are interchangeable, except when multi-framing is enabled on Model-B. In that case, multi-framing must be disabled before changing cards. Note that the default framing mode is non-multiframe (in order to have a compatibility between Model-A & Model-B).

The CESM8T1/B card supports 1:N redundancy.

Table 25 CESM-8T1 and CESM-8T1 /B Feature Comparison

CESM-8T1
CESM-8T1/B

Exhibits multiframe-AAL1 structure misalignment.

Multiframe-AAL1 structure aligned if MF enabled.

The clocking feature of deriving service module line clock can be used.

If MF is enabled, the service module line clock cannot be used to drive the PXM.

Ingress Cell Bus Slave FIFO reset in rare cases may not be synchronized to Cell Bus clock after switchcc.

Fixed FIFO reset logic in hardware (independent of software). This fixes the switchcc related problems.


PXM-UI-S3

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.

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.

The Stratum-3 Clocking feature on the PXM-UI-S3 was introduced in Release 1.1.31, but support was removed in subsequent releases. It is being supported again in Release 1.2.00 and higher.

Hardware Changes

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

VISM Release 2.2 on MGX 8250, MGX 8850 Release 1, and MGX 8230 Switches supported on the PXM-UI-S3 or this release. The external clock interface cannot be used for Stratum 4 with UIS3 backcard.


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)


Problems Fixed in Release 1.2.20

Table 26 lists the problems fixed in the service module firmware and the Release 1.2.20 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.

Table 26 Problems Fixed in Service Module Firmware for Release 1.2.20 

Bug ID
Description

CSCdr71479

Symptom: When using 1:N redundancy on MGX 8250/8850 (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). Upon returning to the original service module the alarm clears.

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 has been confirmed with CESM and AUSM, but is not service module specific.

Workaround: Only known workaround is to not use slot 9 or slot 25 in the 1:N redundancy group.

CSCds26505

Symptom: Cannot generate ilmi signal failure on PXM.

Conditions: unknown.

Workaround: Use external tester to generate ilmi signal failure.

CSCdt35150

Symptom: Console port connection stopped while taking some captures, did not come up after doing 'delserialif 1' and 'addserialif 1'.

Conditions: Normal

Workaround: None

CSCdu50072

Symptom: Deleting APS via SNMP requires "downing" the line.

Conditions: The SNMP interface is used by CiscoView to manage APS for MGX Rel1.

Workaround: Use the "delapsln" command, or de-activate the working SONET line.

CSCdv17041

Symptom: Command line interface on the AUSM is not standard and the format is different when entering VPI in different parameters.

Conditions: Trying to add a VPC connection

Workaround: None

CSCdv69491

Symptom: When two lines on the same AUSM card are connected to each other with only one line enabled, the other line will be in alarm. But if you reset the card, alarm goes away.

Conditions: Lines on the same card

Workaround: None

CSCdv90622

Symptom: AUSM8-E1 card does not support IMA stats

Conditions: Always

Workaround: None

CSCdw52453

Symptom: No trap is generated for APS directional mismatch.

Conditions: Add aps line at both local and remote end. Configure APS so that it has directional mismatch. Now there the trap 50614 is not generated.

Configure APS so that there is no directional mismatch. Trap 50615 is not generated.

Workaround: None.

Further Problem description: None

CSCdw83475

Symptom: tstdelay is inconsistent when run from IGX on a connection between IGX and MGX 8250 feeder. It is longer and varies anywhere between 10 - 40ms. tstdelay at the MGX is consistent and much lower: ~4ms.

Conditions: Can be environment with minimal traffic.

Workaround: None

CSCdx07153

Symptom: QE Access online diagnostics test fails.

Conditions: None

Workaround: If the card is active, switchcc to the other pxm and monitor the diag results. If the card is standby, reset the card once and active monitor the diag results.

Further Problem Description: PXM had a QE ACCESS Online diag test failure. During these QE access failures, it is recommended to switch to the other pxm and actively monitor the old QE failing card for any access failures. If QE failures are still seen, then replace the card.

CSCdx12314

Symptom: Improper output from certain cisco level command

Conditions: Always

Workaround: none.

CSCdx27962

Symptom: MGX1 (1.1.34) node logs do not contain details of post diagnostics. dsplog -mod ONLI will not give you post diag results.

Conditions: MGX1 with 1.1.34 release, and post diagnostics

Workaround: none

Further Problem Description: The post diagnostics results are not logged in the node log. The results are sent as trap to the NMS. CLI will also show proper results.

CSCdx84872

Symptom: xcnfln on the FRSM-E3 card shows incorrect ds3clk display.

Conditions: Condition occurs after issuing the "xcnfln" command. It shows the backplane clock from BNM - it should be backplane clock from PXM

Workaround: None

CSCdy10328

Symptom: Port 4 LED when there's no line/port enable

Conditions: Add/del line

Workaround: none.

CSCdy17762

Symptom: Unable to set the SNMP Object serialPortEnable -> enable (2)

Conditions: This object is used by Ciscoview to enable serialPortEnable

Workaround: None

CSCdy28061

Symptom: chanEgrSrvRate value is not valid.

Conditions: Add a connection on a VHS card. Then change the CIR for this connection. The chanEgrSrvRate doesn't get updated with the new value of CIR. This is a problem if the chanServiceTypeOverride flag is Enabled.

Workaround: Modify the chanEgrSrvRate manually.

CSCdy32860

Symptom: FRSM-HS2B: addlnloop cmd fails and generates exception.

Condition: Add a line on FRSM-HS2B card. Execute cmd addlnloop on the added line. The cmd addlnloop hangs.

Workaround: Unknown

CSCdy32959

Symptom: Upgrade with the cesm-8t1e1 MGXSMNG image causes few conns to be lost after runrev on CESM-8E1.

Conditions: Graceful/Ungraceful upgrade.

Workaround: unknown.

CSCdy44410

Symptom: unable to cc to FRSM_2T3 card after card with SPVC connections.

Conditions: using copychans to create ATM-FRSM connections.

Workaround: reinsert the FRSM_2T3card.

CSCdy51864

Symptom: Cannot add maintenance port (port 2) using addserilaif command after the first serial port is deleted using "delserialif 1" command.

Conditions: Unknown

Workaround: For single PXM MGX 8250 switches there is no workaround. For MGX's with redundant PXM's doing a switchcc will enable both console and maintenance port on its own

Further Problem Description: 1.8.PXM.a > addserialif 2 Set failed due to illegal option value(s)

Syntax: addserialif "<serial_port_num>" Serial Port Number -- a number 1..2

The above output describes the error condition.

If the display is done after deleting the first interface and not reading it, the display may look like the following: 1.7.PXM.a >dspserialif -if 2 Data item not found: serialInterface.serialInterfaceTable.2

CSCdy55338

Symptom: Cell loss outage on switchcc on MGX1 node exceeds 250 ms

Conditions:

1. Switchcc with 1:N redundant groups switched over secondary

2. 50 cps pumped to a ausm with 1:N redundancy

Workaround: none

CSCdy59136

Symptom: Standby PXM card stuck in standby, and active PXM low on buffers. Cannot cc to Active. scmBufCnt shows 3. Com Fails on trunk to BPX.

Conditions: Shelf with AUSM cards, with bulk distribution

Workaround:<

Implementation of trap squelching feature. Preventing the depletion of buffers. The command to be used is addTrapToDropList <trap #> <slot #>

CSCdy60428

Symptoms: switch reason and failure status are not sent in the alarm message for APS

Condition: Unknown

Workaround: None

CSCdy61568

Symptom: Sometimes we get a low voltage alarm on shelves when the DC PEM is switched OFF.

Conditions: Setup: MGX-1 with redundant DC power supplies Event: Turn one DC power supply PEM to OFF position

Result: Sometimes, the 'dspselfalm' output will show low voltage alarm on that power supply. It should show missing

Workaround: Ignore this condition if the voltage column show 9Volts or less. It is equivalent to missing power supply.

CSCdy63295

Symptom: config changes during savecnf should be overwritten on the PXM during restore cnf.

Conditions: While savecnf is going on, make configuration changes from another telnet session.

Workaround: none

CSCdy65498

Symptom: During upgrade of the VISM image, MGX1 redundancy table became corrupt.

Conditions: Unknown

Workaround: None

CSCdy83635

Symptom:<

Router and RPM could not ping each other due to Inverse ARP failure.

Conditions: When OAM-PVC Manage is configured between RPM & switch, then while router interface goes down and comes up, the pouter and RPM cannot ping each other. The reason is OAM-PVC takes time to come up, before which, the inverse ARP fails. If OAM-PVC Manage is not configured, then no problem with the ping.

Workaround: unknown

CSCdz09288

Symptom: The sysName mibObject contains wrong value. Rather than containing the configured node name, this OID contains the switch type.

Condition: Seen on all platforms with a PXM1 controller card [but not PXM1E]

WorkAround: To retrieve the configured node name on the switch, you can use the following OID: 1.3.6.1.4.1.351.110.1.1.3.0 stratacom.basis.basisSystem.basisShelf.shelfNodeName.0

CSCdz18393

Symptom: xcnfln command does not have v.35 option included in the display

Condition: xcnfln command has the option for x21 and hssi, but it does not have the option for v35.

We can configure the line using the x21 option for v.35. But it would be clear if that option also included in the xcnfln command.

Workaround: Unknown

CSCdz18745

Symptom: FRSM-HS2/B is not coming out of mismatch state when we pull out and put back the FRSM-V35 back card.

Conditions: Slot 12 is configured with FRSMH2/B with FRSM-V32/X21 backcard. The card is active state.

The customer pulled out the back card on the slot 12, then the card went into the mismatch state which is a normal behavior. But when the back card is put back, the front card is not resetting and it is not coming as active state. It is stuck in Mismatch state/empty state though the back card is actually present.

Workaround: Execute "resetcd" to reset the card and make it active.

CSCdz22740

Symptom: When running 8 telnet sessions to the PXm on the active slots. The PXM hangs and eventually resets.

Conditions: Run 8 telnet sessions on the pxm for different slots.

Workaround: None

CSCdz23448

Symptom: After RPM softswitch, both Active and Standby RPM are in Standby.

Conditions: Resetting RPM which was Active brought it back to active. Re-issuing

the softswitch command caused the expected results.

Workaround: None

CSCdz25041

Symptom: No hssi option in the xcnfln command

Condition:

1. No hssi option in the xcnfln command

2. Adding the line loopback on the line which has loopback enabled gives wrong error message

Error occurred during the SNMP SET operation!!

Probable Reason: "Cannot change loopback"

SNMP Error Code: 76

Set failed due to illegal parameter(s)

Syntax: addlnloop "line_num"

line number -- 1-2 for HSSI, 1-8 for V.35/X.21

It should say the line loopback is already enabled.

3. When we try to add the loopback with xcnfln command on the line with already enabled loopback it gives the wrong error message

Error occurred during the SNMP SET operation!!

Probable Reason: "Cannot change loopback"

SNMP Error Code: 76

Set failed due to illegal parameter(s)

It should take it or it should say the loopback is already enabled

Workaround: Unknown

CSCdz26819

Symptom: There are no alarms from PXM1E.

Condition: NBSM card has line alarms.

Workaround: None

CSCdz40700

Symptom: dsplog for FRSMHS2/B does not show the line deleted in the message"

Condition: ON FRSM-HSSI Module, line is deleted by using the delln command. But it is not showing in the dsplog that the line is deleted as it shows for other SM modules

Workaround: Unknown

CSCdz42342

Symptom: When issuing "cnfport" on FRSM, card resets.

Conditions: Unknown

Workaround: No workaround at this time

CSCdz42844

Symptom: When using SNMP to poll entries in the OID 1.3.6.1.4.1.351.110.4.3.1.3.1.1 all 'Counter' types are only able to reach 65535. A 'Counter' type should be allowed to max out at 4294967295 (a 32 bit value).

Conditions: This was confirmed using a CESM-8T1E1 card.

Workaround: No applicable workaround.

Polling and clearing the counters on a regular basis is the only way to get accurate information

CSCdz46078

Symptom: dspalms does not have hssi option

Condition: dspalms does not have the " hssi " option as the line type.

However, it does work, if you use x21 option

Workaround: unknown

CSCdz51880

Symptom: SRME logs Path Code Violations under dspalmcnt and VISM line in LOF condition.This is when connected equip using CRC7 J1 byte 16 byte mode

Conditions: SRME RX J1 byte CRC7 mode

Workaround: None

CSCdz54438

Symptom: "dspchan" on AUSM card shows remote NSAP as all zeros.

Condition: The remote NSAP address shows up as all zeros. A PVC was provisioned from: node a to node b. The PVC is up and it can pass data.

Workaround: Unknown

CSCdz62701

Symptom: On FRSM 8 port cards, the customer suddenly sees one port disappearing on a line after the corresponding FRSM line goes in and out of alarm. The problem happens at a very low frequency, once in few months.

Condition: The corresponding FRSM line should go in and out of alarm.

Workaround: Either switchover to the redundant card or delete the port and re-add it.

CSCdz62971

Symptom: MGX 8250 Trap being sent for a MGX 8850

Conditions: Egress Service Queue modification

Workaround: None

CSCdz64276

Symptom: Tried adding an ausm port through snmp scripts, the ausm card is resetting when the line number is not specified during the set operation instead of throwing an error.

Conditions: While adding a port on ausm card through snmp.

Workaround: none

CSCdz74607

Symptom: PXM resets when Trunk Backcard has nvram problem.

Conditions: PXM-T3/E3 having a corrupted nvram of trunk backcard.

Workaround: None.

CSCdz78954

Symptom: frEndPointEgressEcnThreshold cannot be set to 0 for FR connection on

frsm cards on all the platforms.

Conditions: Add a connection on FRSM cards using SNMP set request and provide values 0

(zero) for ECN & DE threshold. The connection addition fails with error ECN & DE threshold should be greater than 0. According to the MIB, the ECN & DE threshold range is 0..2097151 on frsm card.

Workaround: Set the frEndPointEgressEcnThreshold to "1" and not "0"

CSCdz79256

Symptom: Switchredcd on the FRSM-HSSI makes the DTE lines as alarm.

Conditions: When Switchredcd was done from slot 3 to 4.

Workaround: Switch the card back to slot 4.

CSCdz82033

Symptom: On dspcds for MGX 8850 (PXM1),slot 31 is coming up as PXM instead of SRM-3T3. It looks like config file on PXM seems to showing up incorrect for slot 31.

Condition: Unknown

Workaround: None

CSCdz84047

Symptom: The command dspcds displays incorrect backcard information.

Condition: During failure recovery testing, pulled out both back cards from slot-3 and slot-4 of node a, user traffic stopped. Slot-3 and slot-4 are in 1:1 redundancy. A little while later both back cards were re-inserted. Dspcds shows slot-3 as Active/empty and slot-4 shows standby/active...user traffic flowing. Pulled out back card from slot-4 and user traffic still flowing. A cc to slot-3 and a dspcd there showed that line module is present in slot-3 but dspcds is showing otherwise.

Workaround: unknown

CSCdz85683

Symptom: When Router interface bounced, and the RPM switch interface PVC had oam-pvc manage 0, the Router and the RPM could not ping to each other.

Conditions: When the router interface goes down and comes up, FRSM takes time to bring up the ATM connection. If oam-pvc is configured, then the connection will be down till then. By then ARP times out and makes the router i/f down

Workaround: If oam-pvc is turned off, the ARP failure will not happen.

CSCea03252

Symptom: The commands dsppnports & dspports on CESM-8T1E1 have different port status values.

Conditions: Unknown but suspected to happen during switchover of pxm or switchover of the service module.

Workaround: down & up the port on the service module.

CSCea04391

Symptom: FRSM floods dsplog on pxm1e.

Conditions: Anytime an LCN gets out of alarm.

Workaround: Unknown.

CSCea05562

Symptom: On local FRSM-2CT3, some channels not in E-AIS

Conditions: Simulate remote-end LOS (BXM port).

Workaround: Unknown

CSCea06878

Symptom: SRM links are lost after reseating the back card on MGX 8250

Conditions: Reseating the SRM back card.

Workaround: None

CSCea07314

Symptom: The Config Change Trap (50315) for all AUSM IMA Ports (i.e., Add/del/modify) should have line number equal -1. But, When IMA port is configured with only one line, switch is not behaving correctly.

Condition: Configuring IMA Ports using commands - addimagrp/delimagrp, addlns2imagrp/dellnsfmimagrp, cnfportq, add/delrscprtn.

Adding/Deleting channels on the same.

Configuring the trap manager and observing the varbinds sent on executing the above commands.

Also, test the configuration in the following manner:

1. addport 5 1 6

2. delport 5

3. addimagrp 5 1 6 1 -> For this, I received 50315 with line=-1

4. delimagrp 5

5. Verify the varbinds sent in config change trap (Trap# 50315) on executing the above commands.

Workaround: Unknown.

CSCea09535

Symptom: tstdelay on the frsm-vhs cards shows always not more than 2 milliseconds.There is a PVC going through a trunk which has 100 milliseconds delay introduced.

Conditions:

When we execute the tstdelay it shows tstdelay 1 milliseconds. Whereas there is another PVC which is going to the same trunk which is FRSM8E1 end, it shows correct delay of 101 milliseconds.

CSCea13372

Symptom: Soft Loopback on FRSM-2E3 is not looping back traffic

Conditions: Unknown

Workaround: None

CSCea28215

Symptom: VxWorks timer failing after 466+ days. Update to standby fails and even "cc" to other cards would fail.

Conditions: If the PXM card is up and running for more than 466 days.

Workaround: Contact Cisco TAC

CSCea28915

Symptom: Traffic is not passing though on a CESM connection.

Conditions: If there is a line, port, con configured, then those are deleted and the line type is reconfigured and a new connection is added.

Workaround: Reset the CESM card(s).

CSCea30709

Symptom: LOS Trap is sent to PXM before Backcard removal Trap.

Conditions: When you pull out a backcard from Frsm-vhs card.

Workaround: None.

CSCea31928

Symptom: While collecting statistics file when file interval is 't'. You get an additional delay when using the latest version of MGX1.

Conditions: Whenever you try to collect statistics file with the latest version of MGX1.

Workaround: Collect file after one file interval

CSCea35610

Symptom: tstdelay/tstcon needs a return command to get to the service prompt

Condition: Executing the tstdelay or tstcon commands.

Workaround: Unknown

CSCea48204

Symptom: FRSM-HS2/B card keeps resetting

Conditions: After reseating the card

Workaround: Unknown

CSCea52265

Symptom: Incorrect mapping between ports on FRSM-CT3 and the corresponding parifs on the PXM causing the PXM to show the wrong port/con failure(s) for FRSM-CT3 ports/cons

Conditions: Unknown

Workaround: Unknown

CSCea52902

Symptom: One end of a connection is in E-AIS/RDI alarm when the remote end is okay with no alarms.

Conditions: Have a connection between two nodes with -dlci 53 at both ends.

On one node the port and line are in okay state with no signaling alarms while the other node shows E-AIS/RDI.

Workaround: None

CSCin26848

Symptom: Config change trap 50600 sent contains incorrect value for con fig changes tat us varbind.

Conditions: Configuration change for a line.

Workaround: Unknown.


Problems Fixed in Release 1.2.13

Table 27 lists problems fixed in the service module firmware and the Release 1.2.13 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.

Table 27 Problems Fixed in the Service Module Firmware and the Release 1.2.13 Software 

Bug ID
Description

CSCdx40133

Symptom: User will be able to configure the cell bus clock rate to 42Mhz when VISM/VISM-PR resides on the cell bus. VISM/VISM-PR does not support running at cell bus clock rate of 42Mhz

Conditions: When VISM/VISM-PR and any other VHS cards are on the same cell bus.

Workaround: Set the cell bus clock rate back to 21MHz.

CSCdy21804

Symptom: One end of some of the connections will remain alarmed after alarm reason is fixed. The alarm is a false/bogus alarm as the connections are passing traffic and are passing tstcon.

The frequency of the problem is random. The connections affected are random upon reproduction.

This problem severely impact the ability of the customer to manage their network.

Condition: Generate a legitimate alarm (e.g., power cycle the BPX in the middle, or reset the remote SM) then fix the alarm reason.

Workaround: - switchcc on the BPX will clear the problem - on the BPX "dncon" on one connection of the card connections will clear the alarm for all the alarmed connections (looks like the connection to be downed has to be from the same bundle). Then connection can be upped again

- on the SES (for alarmed PNNI connections), dncon, then upcon will clear that connection's alarm. -Deleting the connections and adding them again will clear the alarm. - Resetting the local service module will clear the alarms. - Leaving the connection over long period of time (days) will clear the alarms.

CSCdy31817

Symptom: AUSM ABRFST connection are picking wrong values for PCR,MCR and ICR. Display for AUSM might be AXIS when you cc to AUSM card.

Conditions: When issuing dspchan channel number, third screen will give wrong values for the PCR,MCR and ICR.

Workaround: none

CSCdy60181

Symptom: Connections show abit failure on PXM

Conditions: After executing addln/delln on unused line on the CESM.

Workaround: upcon/dncon on the BPX

Further Problem Description: This is only a display issue. Traffic is not affected.

CSCdy71636

Symptom: The customer sees traffic stop in one direction spontaneously

Conditions: It happens spontaneously on an FRSM 8T1E1 card on the MGX1 shelf. MGX1 shelf is a feeder to an MGX2 shelf.

Workaround: Using CWM reconfigure the CIR of the connection or delete and re-add the PVC.

Further Problem Description: The traffic was stopping because the FRSM card was sending Abit=0 to the CPE. PXM and the other end FRSM show no failures.

CSCdy74077

Symptom: Clock switched to Secondary (Internal if there is no Sec clk src configured.)

Conditions: Issue switchc or switchyred

Workaround:

1. Unconfigure and reconfigure the Inband clock

2. Use external clocking

Further Problem Description: This is caused by the non-revertive nature of Inband clocking

CSCdz01066

Symptom: After adding links for E1-distribution, alarms present on SM line.

Condition: On SM side it is still transmitting RAI alarm and this is only on the line that corresponds to first link added from SRME.

Workaround: When this condition is present, delete and re-add the SM line again.

OR

Add the SRME link first and then add the line at SM side.

CSCdz03912

Symptom: FRSM-HS1/B card resets when entering clrsarcnt without any parameters.

Condition: Entering clrsarnt without any parameters.

Workaround: Always enter the channel parameters.

Additional Information: It does not fail on FRSM8 or FRSM-VHS cards in MGX shelf.

CSCdz22964

Symptom: Display alarm needed for VT/VC level

Condition: This is an enhancement.

Workaround: None


Problems Fixed in Release 1.2.11

Table 28 lists problems fixed in the service module firmware and the Release 1.2.11 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.

Table 28 Problems Fixed in the Service Module Firmware and the Release 1.2.11 Software 

Bug ID
Description

CSCdt22274

Symptom: Sonet port is receiving errors when put in local loopback.

Conditions: When the sonet port is in local loopback, the port errors continue to increment and the line will be in alarm.

Workaround: None

CSCdu61217

Symptom: dspcds and dspcd shows card in major alarm because of line failure. dsplns shows everything is fine.

Conditions: While using addlnloop on the ds1 lines.

Workaround: addds3loop and delds3loop on the ds3 line.

CSCdu66767

Symptom: pxmCurClkSourceTrap is not generated properly.

Conditions: When there is a clock switch.

Workaround: None.

CSCdv40282

Symptom: SMs go into a mismatch/failed state if the SMs and the PXM are reset together.

Conditions: This happened only when the SM and the PXM/ SRM were removed at the same time.

Workaround: Reset the card which is stuck in the Failed/ Mismatch state

Further Problem Description: This was happening because the infobits of the SM were not getting updated due to the PXM switchover.

CSCdw46173

Symptom: Even though the port is in alarm, some channels on the card stop transmitting AIS cells towards the remote end-point.

Conditions: When connection have high channel numbers. It was observed on conns with channel numbers greater than 256.

Workaround: None.

CSCdx21483

Symptom: Cellbus clock rate set incorrectly when two RPM occupy a cellbus.

Conditions: For traffic shaping on RPM, two RPM occupying a cellbus need to have cbus clock rate set to 42MHz. In all other conditions, cbus clock rate should be 21MHz. This is manually configurable today using the cnfcbclk CLI command. Need to have it automatically set.

Workaround: Use cnfcbclk CLI command to set cbus clock rate correctly.

CSCdx33333

Symptom: RPM fails to check the health of IOS image on the MGX hard disk via "debug rpm check_image now c:<image_name>". Same command is successfully executed against the image in the bootflash.

Conditions: This condition was observed after successfully upgrading the RPM card to internally released IOS image.

Issue "debug rpm check_image now c:<image_name>".

Workaround: Copy the IOS image to bootflash and issue "debug rpm check_image now bootflash:<image_name>".

CSCdx45979

Symptom: Receive "ConnPCR greater than port speed" error in attempt to adjust fstPCR on ports.

Conditions: Error seen after removing 1 port from ima group and then attempting to adjust remaining port fstPCR from 10773 to 7182.

Workaround:

Option 1) If there is a need to delete a line from an IMA group, change the connection PCR first and then delete the ima line from the group.

Option 2) If the line has already been deleted from the ima group and now the channel PCR needs to be updated, we have to make sure that we change other parameters and they should also be below the new ima port rate (which depends on the number of lines present) This can be done by using xcnfcon like this: xcnfcon -chn 17 -rs 3 -pcr 7182 -pcr01 7182 -mcr 7182 -pir 7182 -mir 7182 -qir 7182 the mir, qir, mcr can be set to desired values (below port rate), this is just an example.

CSCdx54888

Symptom: The sonet line status tables are not uploaded in the PXM config file.

Conditions: The sonet line status for section, current & path are not uploaded in the PXM config file.

Workaround: None.

CSCdx64136

Symptom: FRSM-2E3 card stops processing data.

Conditions: The problem happens when ALL the following 3 conditions are met:

1. The traffic should be pumped at a rate higher than 33 Mbps (which is close to the port speed on an E3 card of 34 Mbps).

2. The frame size should be between ~ (240 - 300) bytes.

3. The frames sent out of Adtech should be test patterns only.

Workaround: Reduce the traffic rate to 32900 Kbps.

CSCdx68356

Symptom: Framing errors. AIS, Loss of Pattern were seen on the Test Set when one goes through the particular sequence of remote/local loopbacks.

Conditions: Normal.

Workaround: The preventive workaround is to make sure that the line is not in LOS before configuring a remote loop back on that line. To verify this, perform
dspalm -ds1 <line number >

CSCdx71672

Symptom: When a customer performs a special sequence of remote loops to test the CESM unstructured circuits before provisioning CRC errors, Loss of pattern can be seen on the test sets.

Conditions: Problem can be reproduced by putting up some remote loops using a cnfbert command.

Workaround: Resetting the card. Change the CESM port type to Structured.

CSCdx72108

Symptom: PXM throw an exception and then reset.

Conditions: PXM card does not have a TBC. and trying to query the DS3 config such

as config upload or dspln.

Workaround: None.

CSCdx83386

Symptoms:

1. RPM card will not come up with the runtime image using 12.1(5.3)T_XT boot image and 1.2.10, 1.2.02, 1.2.01 PXM images.

2. Upgrade of Latest PXM and IOS images respectively will be affected.

Conditions:

1. RPM should contain 12.1(5.3)T_XT boot image as a first file in the bootflash.

2. Load 1.2.01 or 1.2.02 or 1.2.10 PXM images.

Workaround: Upgrade first RPM cards to the latest image and then upgrade the PXM image.

CSCdx83611

Symptom: cell loss is observed on CESM when tstdelay/tstcon is executed.

Conditions: Always upon tstdelay/tstcon execution

Workaround: None.

CSCdx88630

Symptom: The egress OAM keep alive cells for a voice channel do not get enough bandwidth in the egress direction on an IMA port and as a result the voice PVC goes down.

Conditions: There is enough data traffic to starve the egress OAM queue.

Workaround: none

Further Problem Description: The problem is not specific to but common for IMA groups, in case of IMA groups with multiple lines, when some of the lines go out of the group because of alarm, the port might get oversubscribed as the BW has reduced. In such cases if the data traffic takes up all the bandwidth there is nothing left for the oam flow on the egress side on a port. This means that if there is a pvc using the end to end oam cells as keep alive cells, that PVC will be brought down by the CPE side because AUSM will not be able to send the OAM cells for that pvc to the CPE.

CSCdx89682

Symptom: autoClk does not change cellbus speed immediately after being enabled.

Condition: Cellbus speed is set incorrectly before autoClk feature is enabled.

Workaround: Reload or reseat one of the cards on the cellbus to prompt the autoClk feature to take effect.

CSCdx93715

Symptom: foresight abr connections start dropping frames in the ingress directions.

Conditions: frsm vhs running 10.2.01

Workaround: downgrade to 10.0.23 version

Further Problem Description: Upon upgrading to 10.2.01, the frsm vhs abr foresight connections starts dropping frames in the ingress. The Foresight control loop rate up cells are not acted upon properly causing the connection to never ramp up more than the qir.

Because of this, irrespective of cir, the channel will be serviced only at qir rate in the ingress direction. This causes the ingress q to overflow and hence frames gets dropped because of exceeding q depth.

This happens only to abr foresight connections.

CSCdy17992

Symptoms: Customer is complaining about the minor alarm on the active PXM when they perform a resetcd on the standby PXM. They also see billions of LCVs in the dsplamcnt.

This symptom is different than CSCds60139 where the fix is in the PXM HW.

Conditions: Normal Network Conditions.

Workaround: clralmcnt will clear the errors. Also, these LCVs are bogus and not service affecting.

CSCdy33878

Symptom: tstcon and tstdelay do not work when passing data

Conditions: It looks like a problem with StdABR only. Problem occurs when traffic is received on StdABR connections, tstcon and tstdelay fails.

If there is no traffic receiving on StdABR connections, then tstcon and tstdelay are passing.

Workaround: unknown

CSCdy38334

Symptom: The customer sees traffic stop in one direction spontaneously

Conditions: It happens spontaneously on an FRSM 8T1E1 card on a POP1 shelf. POP1 shelf is a feeder to an MGX 2 shelf.

Workaround: Using CWM reconfigure the CIR of the connection. Or delete and re add the PVC

Further Problem Description: The traffic was stopping because the FRSM card was sending Abit=0 to the CPE. PXM and the other end FRSM show no failures.

CSCdy55571

Symptom: The PCR has no impact on the data xfer for a stdABR connection.

Condition: There is a FR-FR NIW ABR-STD PVC from local node SLOT 19 LINE 6 PORT 10 DLCI 679 to remote node SLOT 20 LINE 1 PORT 1 DLCI 679.

The configuration is CIR =1536 kBPS PCR=MCR=ICR 100 cells

The ADTECH data generator is connected to Line 6 Port 10 of local node. The other end is line looped. Customer could send /receive the traffic at 97% CIR rate (1490 Kbits) without any drops in frames/cells

The PCR has no impact on the data xfer.

Workaround: set the channel IBS to 0.

For a stdABR connection to work properly the IBS should be set to zero.

CSCdy61568

Symptom: DC power supply low voltage cutoff has to increase

Conditions: Unknown

Workaround: Unknown


Problems Fixed in Release 1.2.10

Table 29 lists problems fixed in the service module firmware and the Release 1.2.10 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.

Table 29 Problems Fixed in the Service Module Firmware and Release 1.2.10 Software 

Bug ID
Description

CSCds06755

Symptom: Typo in the help for xcnfilmi command. Instead of showing command name as xcnfilmi, the command name is shown as cnfilmi.

Conditions: Always

Workaround: None

CSCds14597

Symptom: The OC-12 feeder trunk is configured as 1+1 unidirectional mode on the PXM. When Agilent OmniBer 719 testset was used to inject CV-L BER on the protection line, we found deviation on both SFBER and SDBER thresholds set by cnfapsln. The SDBER was configured as 1.0E-7, but was operated at 5.1E-8. The SFBER was configured as 1.0E-3, but the was operated at 1.1E-4.

Conditions: When APS is configured and the line has errors.

Workaround: None

CSCds15474

Symptom: CESM allows incorrect configuration modifications.

Conditions: Modify the timeslot value for an unstructured port.

Workaround: 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: Deleting master connection on the RPM side.

Workaround: None

CSCdt90991

Symptom: The command cnfextclk accepted E1 clock configuration when used to configure an external clock source on a T1 clock port. No warning was given.

Conditions: Normal conditions.

Workaround: Use the correct clock configuration for the external clock source port type.

CSCdu12986

Symptom: Cannot run dsplog cli command on the card.

Conditions: Did not quit gracefully for dsplogs command on other telnet session.

Workaround: switchcc

CSCdu17346

Symptom: CLI clock source commands does not return accurate information about which clock the card is currently using. It shows the card is using external while it is actually using internal.

Condition: External clock configured for E1 but incoming external clock is 1.544 MHz T1 clock.

Workaround: None

CSCdu49191

Symptom: The command cnfimatst does not correctly report back the status of the link if the pattern 255 is used. It will always report "failed" even when the link is fully operational.

Conditions: Always

Workaround: Use data values other than 255.

CSCdu72671

Symptom: Cannot change cell bus rate from CiscoView.

Conditions: Always

Workaround: Use CLI to change the cell bus rate.

CSCdu79023

Symptom: Reset of primary PXM is allowed even if secondary card is not available.

Conditions: always

Workaround: Always use switchcc instead of resetcd to make sure whether the redundancy is available or not.

CSCdu80132

Symptom: Second external clock input on UI-S3 is not available to use Need to support both primary and secondary BITS timing.

Conditions: Always

Workaround: None

Further Problem Description: This is a new feature. With this, the second external clock on UI-S3 back card can be used.

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.

CSCdv11015

Symptom: No Sonet option under the xcnfalm command

Conditions: Always

Workaround: None

CSCdv19158

Symptom: PXM Bootcode burn failed on the standby card with "DB table is full all 20 entries used" logged.

Conditions: Unknown. However, user should avoid using Ctrl-C during saveallcnf/savesmcnf.

Workaround: switchcc

CSCdv28342

Symptom: When you add an incomplete connection from FRSM to PXM with VCI = 0, it's shown as ok.

Conditions: Adding an incomplete connection using VCI=0.

Workaround: Use non-zero VCI.

CSCdv38913

Symptom: Need to discontinue the MIB version# shown in dspcd on PXM.

Conditions: Always

Workaround: None

Further Problem Description: For further details, refer to MIB release notes.

CSCdv48510

Symptom: 1) active core card set SRM showing "mismatch" because of missing back card

2) standby core card set PXM showing "mismatch" because it has SRM card

3) unable to switchcc because core card set not available

4) after inserting the SRM backcard, get message "PXM Switchover for SRM Failure" on the active PXM but it does not switch.

Condition: Pull out standby SRM back card.

Workaround: Insert standby SRM back card.

CSCdv54796

Symptom: The downloaded information from the switch shows the backcard as removed even if it is not present.

Conditions: When the back card of an ausm-8t1e1 is removed.

Workaround: None

CSCdv56773

Symptom: Command line is hung issuing display requests. Customer experienced hung Command Line Interface and could not issue any normal display requests.

Commands such as dspcds, dspcons or dspalms, which have more than one page output, would cause the CLI to hang.

Conditions: A command with multiple page output was issued and when it prompts for <Return> or `Q', no input was given and the telnet session was left idle.

Workaround: Switchcc

Further Problem Description: The fix basically makes the CLI to timeout if user doesn't specify the input in 30 seconds. It applies to prompts like: Type <CR> to continue, Q<CR> to stop: and also: Do you want to proceed (Yes/No)?

CSCdv62107

Symptom: Unknown line number sent by switch for PXM-OC12.

Conditions: When PXM-OC12 is used.

Workaround: None

CSCdv79466

Symptom: Sometimes oldiag fails on standby PXM. Node will be placed in major alarm due to the standby PXM oldiag failure.

Conditions: oldiag fails attempting ipc with the standby PXM.

Workaround: None

CSCdv81736

Symptom: SM Card seen to reset continuously.

Conditions: Previously saved PRI File downloaded to the switch. Connections provisioned after this.

Workaround: Reset the card after the PRI file download.

CSCdv89742

Symptom: clralmcnt <CmdArg>-ds3<noCmdArg> does not clear the counters for the SRM.

Conditions: Always

Workaround: Use clralms <CmdArg>-ds3<noCmdArg>.

CSCdw01992

Symptom: PXM spontaneously switched over. The following error messages scrolled across the screen

################################### ###### 
SYSTEM ERROR 20182 -426933 2025115134 50338856 -2029099400 
################################### 
vsim fatal: can't get message buffer

Conditions: Flapping DS3 lines on SM/SRM, which can cause buffer depletion on controller card.

Workaround: Clear the alarm or add loopback on the line.

CSCdw02483

Symptom: Couldn't add maximum number of connections on FRSM-HS2/B card under certain conditions.

Conditions: Unknown

Workaround: None

CSCdw03604

Symptom: Inconsistency in databases on CESM-T3/E3. The lines, ports and connections remains out of alarm. But one of the cards remains in major alarm.

Conditions: Master connection is added before adding the slave connection.

Workaround: Add the slave connection before adding the master connection.

CSCdw05153

Symptom: Stats file only contains header. No data is actually lost. The same file becomes available within 2 minutes 40 seconds, even on a maxed out shelf.

Conditions: Stats file is requested immediately after the expiration of the interval.

Workaround: Collect Statistics about 3 minutes after the interval expires, or, reduce the number of items that stats collection is enabled for.

CSCdw09468

Symptom: When dsperr with page mode off after an interval the PXM switches over

Conditions: Issue dsperr command pagemode off.

Workaround: Before issuing dsperr, make sure that pagemode is ON by issuing pagemode. If it's OFF, use pagemode ON command.

CSCdw10286

Symptom: CESM T3E3 card goes into Major alarm after addcon CLI is executed with the slave parameter.

Conditions: Execute CLI addcon 1 2 on the CESM T3E3 card

Workaround: None.

CSCdw13465

Symptom: The config file of 8850 contains incorrect information for SRM. The card information table of SRM is replaced by the card information table of PXM

Conditions: Not known.

Workaround: None

CSCdw18114

Symptom: Port LED blanks out when "runslftstno 6" is entered. Port LED blanks out, Line/Port/Channel configuration disappear and DATA stops when runslftst no 8 is entered.

Conditions: Normal

Workaround: None

CSCdw20626

Symptom: T3E3 card does not show card minor alarm when connection is in alarm because of cell loss.

Conditions: Cell Loss alarm on a connection. This can be caused as a result of:
1. A bit alarm on a connection
2. Errors in the transmission of the data.

Workaround: None

CSCdw26129

Symptom: When the redundant card fails, no trap gets generated.

Conditions: Always

Workaround: None

CSCdw34721

Symptom: RcvRAI count does not increment in dspalmcnt for SRM DS3

Conditions: When the SRM DS3 line is receiving RAI.

Workaround: None.

CSCdw37004

Symptom: Cannot ping IPV6 address across an FR link on FRSM card.

FRSM does not respond to IPv6 packets.

Conditions: Unknown

Workaround: None.

CSCdw40834

Symptom: SNMP traps are sent from the PXM to management station indicating a DS3 alarm on the SRM of the MGX 8250/8850. When checking via CLI command dspalmcnt there are no alarm counters incremented. In the PXM log, viewed via dsplog there is an entry similar for: VSIS_TRAP: DS3 Minor Alarm hence not reporting 805371649

Conditions: This has been seen when using the DS3 lines on the SRM.

Workaround: None

CSCdw42720

Symptom: Repeated add/Del channels on cesm-8t1e1 causes card to reset.

Conditions: Repeated add and delete channels on cesm-8t1e1

Workaround: None.

CSCdw47655

Symptom: PXM1 report major alarm if DC is missing.

Condition: Always.

Workaround:

1) on the card, do a dsppostresults, make sure framer test is the only one that is failing.

2) confirm that the customer do not have a DC card

3) on the pxm, do following: shellConn clrPostAlarm

CSCdw65157

Symptom: Channel state inconsistency between CPE and the FRSM card

Conditions: SIW(service interworking) connection between BXP and FRSM on MGX 8220 feeder. RDI alarm generated in ATM network. Traffic load is none or normal.

Workaround: None

Further Problem Description:</B>

The RDI (Remote defective identifier) coming from the ATM network by a Service Interworking connection, is not correctly mapped into a-bit on the Frame Relay side(AXIS - FRSM card) of the same connection. Therefore, the Frame Relay CPE won't be able to detect this far end failure.

CSCdw65398

Symptom: Inconsistency in the channel states between the CPE and the FRSM

Conditions: SIW(service interworking) connection between BXP and FRSM on MGX 8220 feeder. RDI alarm generated in ATM network. Traffic load is none or normal.

Workaround: None

Further Problem Description: The RDI (Remote defective identifier) coming from the ATM network by a Service Interworking connection, is not correctly mapped into a-bit on the Frame Relay side(AXIS - FRSM card) of the same connection. Therefore, the Frame Relay CPE won't be able to detect this far end failure.

CSCdw66303

Symptom: MGX 1 stops providing backplane clock to the SM and this causes CESM card to rebuild itself.

Conditions: Happens when the UI-S3 backcard is pulled out with the current clock level configured as Stratum 3.

Workaround: Perform a switchcc and the make the current PXM standby before pulling out the UI-S3 backcard.

CSCdw69926

Symptom: MGX1 does not use the inband clock reference when the clock level is Stratum 3.

Conditions: PXM should have a UI-S3 backcard and the current clock source is inband from the feeder trunk. The clock level should be Stratum 3.

Workaround: If inband clocking is needed in Stratum 3 level with UIS3, following workaround should be applied in the sequence given below:

1. Manually drop the clock level to S4: cnfclklevel 4

2. Configure the clock source as inband: cnfclksrc 7.1 p

3. Jump the clock level to S3: cnfclklevel 3

4. Reconfigure the inband clock source: cnfclksrc 7.1 n cnfclksrc 7.1 p

CSCdw69982

Symptom: FRSM-8E1 keeps resetting.

Condition: When more than 189 ports are enabled on the card and all port and channel statistics are enabled with the peak enabled flag set.

Workaround: Enable fewer channel/port stats for the card.

CSCdw70376

Symptom: tftp of the config file by the CWM from the RPM-PR card takes a long time

Conditions: Happens under all conditions

Workaround: An alternate method to do tftp fetches the file successfully.

The steps are as follows bodc-xdm1% tftp mig1pop1 tftp> bin tftp> trace Packet tracing on. tftp> get RPM/auto_config_slot03.

CSCdw70652

Symptom: When new connections are added on a Channelized E1 line/port, bit Errors will be logged on a BERT Tester connecting to the same line on a DAX connection.

Conditions: Adding/deleting connections on the line will cause the problem regardless if it has been added via CWM or CLI

Workaround: None

CSCdw73702

Symptom: 1+1 OC12 APS configured; WLine in alarm, Forced switchaps P->WLine failed.

Conditions:

1. 1+1 OC12 APS connected to AXSM/B cards with Bi-dir & Revert mode.

2. Removed WL-Rx line from AXSM/B end.

3. Issued Forced Switchaps P->WLine from PXM1 end.

Workaround: Do Forced Switchaps from AXSM/B end.

CSCdw73786

Symptom: Standby PXM reset with core dump.

Conditions: Unknown

Workaround: None

CSCdw76794

Symptom: Sonet Line reports receiving RDI even after the physical cable is reconnected

Conditions: PXM ver: 1.1.40 Insert the Rx End before the Tx end.

Workaround: switchcc clears the anomaly if there are no ports (or connections) on this line, delln and addln will work

CSCdw84584

Symptom: Manually switch from a protect line to a working line results in unexpected MS response and is preceded by an "Unexpected request [DO NOT REVERT]" message followed by several APS_PLINE_FAILU and APS_PLINE_CLEAR messages.

Conditions: Configure 1+1 APS bi-directional APS, and perform manual switch from a protect line to a working line.

Workaround: Unknown.

CSCdw86752

Symptom: Upgrade of AUSM card with IMA ports cause database inconsistency

Conditions:

1. AUSM card with IMA ports

2. PXM version is lower than 1.2.10 3. upgrade AUSM

Workaround: Cisco upgrade script

CSCdw89912

Symptom: CESM-8T1E1 comes up as failed after it boots up.

Conditions: This occurs after the shelf on which the card is present, is power cycled. This behavior is intermittent.

Workaround: Reset the card which is stuck in the failed state.

CSCdw90917

Symptom: Users in user groups lower than super user are able to run this cmd clrallcnf.

Conditions: always

Workaround: None.

Further Problem Description: Other commands that changed to superuser access level are:

clrsmcnf - from group3

resetcd - from group3

resetsys - from group3

Other commands that changed to group1 access level are:

switchcc - from group3

clrerr - from anyuser

CSCdx07493

Symptom: The DE-CLP, FECN-EFCI mappings and the RM cell generation are working as required. But some customer require the mappings to be enabled for stdAbr connection even though the standard does not allow it. Hence making the mapping for stdAbr configurable. The default is as it was, no mapping

Conditions: The DE-CLP, FECN-EFCI mappings for stdAbr connections

Workaround: None

Further Problem Description: The DE-CLP and the FECN-EFCI mapping is not supported for stdABR connections as per the standards. But since there is a need for some customers we are making the DE-CLP and FECN-EFCI mapping and the generation of the RM Cell configurable.

CSCdx16508

Symptom: The throughput of the FRSM-2ct3 card degrades to 50%.

Conditions: There are multiple conditions to be met for the performance to degrade. And all the conditions have to be met simultaneously. The conditions are

1. Bidirectional traffic on the port.

2. The ingress traffic should be greater than 75% of the T3 rate.

3. The egress traffic should be much greater than the T3 rate

4. The connection is a SIW-x connection

5. The egress port servicing is Weighted Fairness Queuing

6. The AAL5 frame length in the egress direction should be 86-88 bytes

Workaround:

1. To avoid the problem use Ratio Based Egress Port Servicing instead of Weighted Fairness Queuing.

2. If the throughput has degraded the card must be reset.

CSCdx32909

Symptom: The port on the CESM card remains active.

Conditions: The line is failed due to reasons other than Loss Of Signal or Loss Of Frame. Examples of these other line alarms are receive AIS, receive RDI, etc.

Workaround: None.

CSCdx34587

Symptom: Shelf is unreachable, no traffic is passed.

Conditions:

1. Shelf has to reset ungracefully. A window of 20 secs between the 2 pxm resets.

2. Do a switchcc after the shelf has recovered.

Workaround: Execute another switchcc.

Further Problem Description: After an ungraceful shelf reset (i.e other than resetsys) and when the window between the two pxm resets is 20 secs, the line driver in the newly standby card is not properly initialized. Due to this, When a switchcc is done after the shelf has recovered, "Unreachability" will be seen on the bpx. No traffic will be passing from the network into the shelf.

To identify this situation

1. verify there are no line alarms.

2. use the cli dspatmlncnt <line_no>. Do this CLI for a couple of times and see whether the receive cell count is incrementing.

3. do tstcon for a couple of channels that were previously OK.

If the output doesn't increase and tstcons fail, then we have fallen into this situation. To recover from this situation gracefully, wait for the stdby pxm to come up standby and do a switchcc.

CSCdx48937

Symptom: ICR doesn't get configured properly when the tbe value is huge.

Conditions: StdABR connections with non-zero values of tbe and frtt.

Workaround: None.


Problems Fixed in Release 1.2.02

Table 30 lists problems fixed in the service module firmware and the Release 1.2.02 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.

Table 30 Problems Fixed in the Service Module Firmware and Release 1.2.02

Bug ID
Description

CSCdx06855

Symptoms: Configuration is getting corrupted after wr mem in 12.2(4)T to T3 images.

Conditions: When wr mem is performed, using copy <src> <dst>.

If <src> is running configuration and <dst> is PXM disk, the corruption will occur.

If <src> is running configuration and <dst> is other than PXM disk, corruption will not occur.

Workaround: Instead of using wr mem, the following 2 steps are the procedure to save configuration properly on the PXM disk.

1. issue "copy run bootflash:<dummy-file>"

We recommend the dummy-file is named "start-up" to make it more readable. Since we are not writing to the disk, the tag is not added.

2. issue "copy bootflash:<dummy-file> start"

Since we are saving a file from bootflash to the start-up, this works fine too.

Additional Information: Note, the problem is seen with 1.2.01 and IOS versions 12.2(4)T3 or lower only. The problem is not seen with MGX 1.2.00 or lower.

CSCdx14043

Symptom: While upgrading AUSM service module firmwares, some of the connections go in to inconsistent state.

Conditions:

1. Ausm upgrade with change in the MIB.

2. have a mix of ima ports and ausm ports and channels existing on both of them.

3. pxm fw 1.1.41/1.2.00 or earlier.

Workaround: delete and re add the inconsistent connections. If there are too many connections contact Cisco for support.

Further Problem Description: While upgrading an AUSM firmware from one version to later version having a MIB change and have ima ports and ausm ports, the connections go inconsistent. After the upgrade, the chkslotcon <slotno> would show inconsistent connections.

Though the connections are inconsistent, the hardware is still programmed and there wouldn't be any traffic impact as long as the pxm doesn't switch over.

The hardware programming will be lost when the pxm switchover happens.


Problems Fixed in Release 1.2.01

Table 31 lists problems fixed in the service module firmware and the Release 1.2.01 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.


Note Due to CSCdx06855, MGX 1.2.01 is no longer generally available and has been deferred. This DDTS has been resolved in MGX 1.2.02.


Table 31 Problems Fixed in the Service Module Firmware and Release 1.2.01 

Bug ID
Description

CSCds25917

Symptom: The xdspsrmlink cli command does not output an error message when no argument is given for the command.

Conditions: Whenever xdspsrmlink is executed without any arguments.

Workaround: No workaround.

Further Problem Description: xdspsrmlink command is not displaying error messages properly when it is called from the cli prompt without any arguments. The command instead prints that the table is empty, even when the table is not empty.

CSCdu54875

Symptom: xcnfchan doesn't change the service rate after upgrading to 1.1.34

Conditions: For Connections created in 1.1.2x This happens because the ChanServiceRateOverride and the ChanServiceRate was not initialized after the upgrade. This caused the mir,qir,pir to be calculated based on the ChanServiceRate (which was 0).

Workaround: Configure the ChanServiceRateOverride to the default value (disabled) using either

cnfchansrvrate <channel no> 2 <chan service rate>

or

xcnfchan -chn <chan no.> -en 3 -srvovrd 2

CSCdv15625

Symptom: Addlnloop on the srme card did not get the expected result.

Conditions: add line on srme oc3 card, addlnlloop on the srme line

add a line in one of the SM's say FRSM on slot 1 line 1

addlink between slot1 line 1 to srme line. we can see that the line is still in alarm

Workaround: The problem is because of hardware limitation. Supermapper chip has a version 2.0 which does not support the addlnloop. The newer version i.e., 2.1 or above supports addlnloop command. If we upgrade the supermapper to newer version then we should not see this problem.

CSCdv50663

Symptom: tstdelay at pop2/axsme failed across an XPVC with axsme and frsm-8t1 endpoints

Conditions: tstdelay started from axsm-e of an XPVC which has pop2/axsme and pop1/frsm-8t1 a tstdelay initiated from frsm-8t1 end works fine

Workaround: none

CSCdv62135

Symptom: bootChange command should have password authentication.

Conditions: This applies to all existing PXM versions.

Workaround: None

CSCdv66013

Symptom: Configuration of the APS line goes through even though the line has not been enabled for APS.

Conditions: The happens on a line on which APS has already been enabled and disabled. Once in the disabled state the APS parameters can be configured without enabling the line for APS

Workaround: Configure the APS parameters only after enabling the line for APS.

CSCdv73162

Symptom: Table Load exception error while resetting PXM using ctrl-x

Conditions: During resetting a PXM using ctrl-x from console.

Workaround: None.

CSCdv76409

Symptom: abrfst pvc's on AUSM not rating down to MCR when run over congested BXM

Conditions: Lab environment. Manufactured congestion.

Workaround: Configure IBS = 0

CSCdw02677

Symptom: FRSM-2CT3 keeps resetting on a certain enable.stats file.

Condition: When there are more than a hundred ports and all port statistics are enabled with the peak enabled flag set.

Workaround: Disable the new stats ID 25, 27,28

CSCdw08896

Symptom: Node went unreachable, could not execute dsptrks, dcondb 4 3. Could execute dspchans, and dsptotals

Conditions: At the point in time when the Node went unreachable, the logs did not have any obvious indication that LMI task failed.

Workaround: No workaround was required, as 11 mins later, the cards (PXM) switched over automatically, restoring service.

CSCdw09173

Symptom: Channel state on the CWM GUI is inconsistent with that of the switch

Conditions: It happens under the following sequence of events - Channel fails due to Abit alarm - Port for that channel fails - Port for that channel clears

Workaround: None

Further Description: When the above mentioned conditions happen then the CWM database will show the connection state as OK instead of Fail as in the switch. To circumvent this problem, with the current implementation of CWM, the switch needs to send channel traps for all the failed channels once the port comes up.

CSCdw09742

Symptom: AUSM channels experiencing EgressPortQ discard after a switchcc.

Conditions: The channels experiencing the problem is on a line using bulk distribution The line is configured as LoopTiming

Workaround: Reset the AUSM card.

CSCdw11628

Symptom: Async updates are not sent out under certain conditions.

Conditions: When both async updates and full updates are enabled.

Workaround: Only async updates should be enabled.

CSCdw11644

Symptom: Frames shown to be tagged DE on a non tagging connection

Conditions: traffic more than CIR and CLP to De mapping ignored.

Workaround: This is a display problem, frames are not being tagged.

CSCdw23460

Symptom: Softswitch sometimes disturbs traffic flow.

Conditions: 1:N Redundancy

3. The secondary card had some configuration before being configured to secondary.

Workaround: Before configuring a card to be the secondary card for 1:N redundancy, make sure that it does not have any configuration. Do a clrsmcnf for the card if it does have any configuration.

CSCdw33698

Symptom: The immediate symptom is that an MGX-8250 is not discovered from CWM. Even if telnet access to the switch exists, and pings are replied, snmp packets are not.

Conditions: The CWM station (or workstation origination snmp packets) has a different subnet mask than the MGX Switch, doing VLSM. CWM and MGX are not in the same ethernet segment.

Workaround: Change the subnet mask so that they match. Modify the subnet mask in the MGX-8250.

Further Problem Description: The problem can be seen in situations such as this:

CWM 192.168.100.79/24 | Router | MGX-8250 192.168.101.70/28

The MGX Switch mistakes the source IP Address for a broadcast address and therefore does not reply.

CSCdw34701

Symptom: The SRM DS3 line alarm logs are not detailed

Conditions: When there is a alarm on the DS3

Workaround: None

CSCdw40773

Symptom: In 1+1 APS, the channel number is incorrect for WTR and DNR after SD clears on working line.

Conditions: Configure 1+1 APS and create SD condition on working line, then clear the SD condition.

Workaround: None.

CSCdw41946

Symptom: Loss of RPM configuration.

Condition: The auto_config_slot<x> file size is set to zero resulting in an invalid con- figuration.

Workaround: UNKNOWN

CSCdw47936

Symptom: cnfapsln does not send out trap 50613

Conditions: trying to configure APS

Workaround: none

CSCdw47943

Symptom: Configure upload file contains incomplete APS information

Conditions: Always

Workaround: none

CSCdw53351

Symptom: DE-CLP and FECN-EFCI mapping doesn't work properly for some configurations.

Conditions: StdABR connection on a FRSM-8t1e1

Workaround: None.

CSCdw54609

Symptom: APS on a PXM1 line can not be added via SNMP, after a resetsys, unless the APS is added and deleted via CLI first.

Conditions: Any PXM1 hardware running MGX Release 1.1.x or 1.2.01 and below.

Workaround: Add and delete the APS via CLI for the first time. Subsequent provisioning via SNMP will then work. This has to be done on each line.

CSCdw55029

Symptom: Failed to CC to RPM card

Conditions: Added sub interfaces and connection using scripts.

Workaround: switchcc

CSCdw56886

An error can occur with management protocol processing. Please use the following URL for further information: http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCdw65903

CSCdw66418

Symptom: delapsln trap contains a wrong slot number of 0

Conditions: Always

Workaround: None

CSCdw68321

Symptom: default value of lineClockType for a HSSI interface of HS2/HS2B is NonInvertedAndLooped instead of NonInvertedAndNotLooped

Conditions: Always

Workaround: None


Problems Fixed in Release 1.2.00

Table 32 lists problems fixed in the service module firmware and the Release 1.2.00 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.

Table 32 Problems Fixed in the Service Module Firmware and Release 1.2.00 

Bug ID
Description

CSCdr61328

Symptom: The delete bit is not set in the Async Lmi Packet when a connection is deleted.

Conditions: The delete bit in the Annex-A/Annex-D has been masked hence the delete bit is not set in the Async Lmi Packet when a connection is deleted.

Workaround: None.

Further Explanation: Scenario:

1. Configure a port with PVC Asynchronous Status Report enable.

2. Add a PVC.

3. Delete the PVC.

Problem: 1. The "Delete bit" in the PVC IE is not turned on.

CSCdr88604

Symptom: The alarm on SRM lines are not getting updated. Even when the line is deleted the alarms exist.

Conditions: Workaround: Do clralm on the deleted line which has the alarms.

CSCds01403

Symptom: There is a mismatch in usage syntax in dspportq.

Conditions: When execute the dspportq without parameters and with non-numeric characters.

Workaround: None.

CSCds02030

Symptom: cnfcon and xcnfcon allows mcr value = 0, which is different from given syntax.

Condition: When execute cnfcon and xcnfcon with mcr = 0.

Workaround: None.

CSCds05040

Symptom: 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.

Conditions: If the SRM backcard in the redundant core card set is removed and reinserted, the alarms on the shelf will be clear, but the MAJ alarm LED alone will be left turned on.

Workaround: Perform switchcc to clear the LED.

CSCds07944

Symptom: clralmcnt -ds3 does not clear the counters.

Conditions: Workaround: Use clralms -ds3

Further Problem Description:

CSCds10270

Symptom: When a OC-12 feeder trunk is configured as 1+1 unidirectional mode, the PXM-622 OC-12 line on slot 7.1 of peartx40 MGX node did not have the option in specifying whether the "working" or "protection" line would be applied upon an external request such as "Manual Switch" and "Forced Switch". This will prevent the capability to allow a user to change a request from "MS: W->P" to "FS: W->P" directly. The options allowed under the "switchapsln" command are listed as below:

Conditions: With APS configured and trying to do switchapsln.

Workaround: None

Further Problem Description: None

CSCds21131

Symptom: The LineOOFCriteria on a PXM card with DS3 daughter card shows "fBitsOf16" when configured for "fBits3Of16".

Conditions: Applies to PXM with T3 trunk module.

Workaround: None.

CSCds26477

Symptom: Displays wrong Front card description for CESM T3/E3 cards.

Conditions: For CESM T3/E3 card, Cisco View displays wrong description for front card description field.

Workaround: No workaround.

CSCds27547

Symptom: The BERT test were running on two Service modules: one in the upper bay of the Popeye node and one in the lower bay of the popeye node but dspbert was displaying only one of them. Once the BERT was deleted on that slot, then only dspbert showed that the BERT is running on the other slot.

Conditions: Workaround: Use dspbert <second slot#> to verify whether the BERT is running on the second slot or not.

CSCds29448

Symptom: The line status for disabled lines in line table shows inconsistent in database.

Conditions: This happens when repeated queries are being done on the switch for line alarm_state from the CWM workstation.

Workaround: Under investigation.

CSCds34186

Symptom: LMI is not functioning as per requirement for FUNI.

Also, attempting to configure LMI for a FrFowarding port is not allowed but the error message is somewhat confusing.

Conditions: Whenever LMI is configured for FUNI.

Workaround: Under Investigation.

CSCds37553

Symptom: Port shows ILMI failure though there is no failure.

Condition: Happens on 5.x firmware with version 5.0.12

Workaround: Card reset or softswitch clears this problem.

CSCds38145

Symptom: Lmi debugging facilities to be ported from AXIS.

Conditions: Not applicable

Workaround: Not applicable

Further Problem Description: The LMI debugging facilities provided in the FRSM_HS1 of AXIS is to be ported to POPEYE branch.

CSCds38166

Symptom: On PXM with Stratum-3 backcard (UI-S3), the external clock src, configured as E1, seems to revert to T1 after a switchcc. The dspclkinfo command output says it is a T1 clock. ***APPLIES to UI-S3 backcards _and_ the external clock source of E1 only.

Conditions: No service impact. Display is wrong. The clock source is still external and E1. However, the workaround MUST be implemented to after every switchcc to make sure there is no further service impact after subsequent switchcc's.

Workaround: After every switchcc, execute the command: cnfextclk 2 This will update the necessary fields, correct the dspclkinfo output, and prepare the shelf for subsequent swithcc operations.

Further Problem Description: The bug only effects Stratum-3 backcards. 1) The bug is not service effecting (display issue) 2) a workaround exists 3) there are indirect indicators that show the actual state of the clock source.

Here is a brief description: Synopsis: CSCds38166 -- External clock cnf of E1 lost on switchcc In reality, the logic that reads the HW registers and displays the output of the dspclkinfo command is flawed. Root cause: Actually, what happens is, the field that determines the value of the clock input jack is used to determine whether the source is an E1 or a T1 clock. This works fine for Stratum-4 backcards, but for Stratum-3 backcards, the same input is used for T1 and E1, so the logic defaults the display to t1. The clock source is still external clock, and no service is impacted.

Impact: After the first switchcc, there is no service impact. However, there is a danger for a subsequent switchback: Since once the field is wrongly updated to "t1", on switchcc, the PXM that takes over will try to find a T1 clock input, and will fail, switching to internal clock.

Workaround: After every switchcc, login to the shelf and do a:"cnfextclk 2". This will cause all fields to get updated correctly, and will enable a subsequent switchcc to not lose external E1 clock. This command will also straighten out the display of the command dspclkinfo.

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 into 8250 using a newly created userid.

Conditions: In 8250 releases 1.1.30 to 1.1.32, new user account is created with adduser CLI and subsequent xcnfuser CLI.

Workaround: Create the new user account with adduser CLI. Then before the xcnfuser CLI is used for the newly created account, login using the new account from another terminal and logout.

CSCds67365

Symptom

These bug is opened to resolve the warnings reported by a code coverage tool PREfix. The warnings reported include "uninitialized variables" etc. Hence the symptom for this bug is unknown.

Conditions

Normal working conditions

Workaround

None.

CSCds77223

Symptom: Changing the ingressq to the minimum value of 4510 on a FRSM card causes all traffic to be discarded. This occurred on 1.1.23 and 1.1.31.

Conditions: Change of ingressq to the minimum value of 4510

Workaround: Changing the minimum ingressq to 4511 fixes the problem.

CSCds81198

Symptom: dspcons display on FRSMHS1B is not aligned starting from channel field

Conditions: addcon on FRSMHS1B on POP1/1.1.32 then run dspcons

Workaround: None.

CSCds87189

Symptom

RcvLOS count toggles between 0 and 252.

Conditions

When executing addds1loop/delds1loop.

Workaround

None.

Further Problem Description

None.

CSCds90673

Symptom: The card is in Bulk Mode Now as the SRM Line is in alarm the line/port/connection are also in alarm. Now if we reset the card, the line/connection are still in alarm as expected but the port i

Conditions: When the card is put in Bulk Mode & then a reset card is done.

Workaround: Problem under investigation.

CSCds91080

Symptoms;

The command addport with wrong port type causes Data Bus Error

Condition: The command addport on frsmhs1b using wrong port type (other value than 1 or 2 or 3).

Workaround: Use only valid port type values (1, 2 & 3)

CSCdt05984

Symptom: The command xcnfchan does not display the setup options correctly

Conditions: xcnfchan command on FRSM3T3

Workaround: None.

CSCdt18908

Symptom: The command dspcons on FRSM-2T3 increments ChanNumNextAvailable field and skips 1 channel when adding next connection.

Conditions: Issue addcon command and monitor ChanNextNumAvailable field.

Workaround: None.

CSCdt19174

Symptom: dspcons increments ChanNextNumavailable field and hence addcon skips next channel number by one.

Conditions: When adding connections and using dspcons.

Workaround: None.

CSCdt19187

Symptom: dspcons or dspchans increments the LocalVpIdNextAvailable by 2.

Conditions: When performing dspcons/dspchans.

Workaround: None. Not Service Impacting.

CSCdt28566

Symptom: Frames are getting dropped due to port queue overflow without any frames being tagged on the egress direction. dspchanct for the channel would show increasing values for FramesDiscarded count and FramesByteDiscarded in the Tx direction. dspportcnt for the port would show increasing values for XmtFramesDiscXceedQDepth and XmtBytesDiscXceedQDepth in Tx direction.

Conditions: This occurs when the Queue threshold for the port is configured very low.

Workaround: use cnfegrq cli to configure the queue threshold accordingly. Note that in case of Ratio Based Servicing, the queue number of high priority is 1 and low priority is 2. In 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 cnfegrq does not update the cached copy of the port queue thresholds. Hence reset is necessary to get the configuration into effect. More over, dspegrq clis should be unblocked to make it available irrespective of the type of servicing algorithm used in the card. Also, the cnfegrq should be fixed to update the cached data structure and display proper queue numbers to use during different servicing algorithms.

CSCdt40267

Symptom: CAC override is not sent to the CWM in the config upload file

Condition: This parameter is not included in the config upload files.

Workaround: No work around till the CAC override parameter is added to the config upload file. This has been added to the config upload file to fix this bug.

CSCdt43225

Symptom: Some channels are stuck in alarm. dspchancnt shows that the channels are receiving OAM AIS, but dspsarcnt does not show that OAM AIS is received. The far end is not sending OAM AIS either.

Conditions: This problem happened when the CPE equipment was connected to the port.

Workaround: Fail the port and recover it (by changing the port signalling).

CSCdt45615

Symptom: Misleading log message when back card is missing.

Conditions: When Backcard is missing.

Workaround: None.

CSCdt76729

Symptom: Remote Loopback operation is not blocked by CiscoView on a AUSM 8T1 line. There will be no traffic continuity on the line after a remote loopback is added and removed.

Conditions: Add a remote loopback on AUSM8T1 and remove it. Data continuity is lost.

Workaround: Workaround is after adding and removing the remote loopback on the AUSM line one has to add and remove a local loop on that line again through CiscoView

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 internal for up to 10 seconds.

This is a problem as it causes errors on 64K unrestricted data calls and could also cause problems on high speed modem calls.

Conditions: External clock configured on the node.

Workaround: None.

CSCdt90660

Symptom: The FRSM-VHS card goes to failed state and after Redundant card takes over all lines go into alarm.

Conditions: Trunk errors on the BPX trunk through the failed card has connections routed through.

Workaround: Reset the Failed VHS card.

CSCdu00363

Symptom: Connections shows invalid PCR after deleting links from ima grp.

Conditions: When you have connections configured under an ima group & then you try to delete few links from the existing ima group by executing CLI: dellnsfmaimgrp.

Workaround: None.

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.

CSCdu03185

Symptom: Allowing more than expected CLP1 cells into the network by the policing function on VBR.2 (rt/nrt) connections on AUSM 8T1.

Condition: This could potentially lead to network congestion.

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 for remote request of equal priority is not in place.

Workaround: None.

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.

CSCdu14185

Symptom: Unable to add RPM connection

Conditions: Condition was caused by using CM and adding the ATM(RPM) to ATM(RPM) connection from MGX 8250 to MGX 8230 and the error was: Connection add request to PXM failed.

Workaround: Using CM to add 3-segment connection: ATM(RPM) - ATM(RPM).

CSCdu17049

Symptom: On an MGX 8250 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 (e.g., 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 RMP.

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).

CSCdu21136

Symptom: Channels do not come up to the active state.

Conditions: After a softswitch is done between slots 22, and 30, then a switchcc.

Workarounds: Do a second switchcc, and the channels come up to the active state. Increase the value of gu32TimeoutValue to 500 in shellConn on the AUSM before doing a switchcc.

Further Problem Description: The problem happens because of management buffer depletion causing the IMA active trap to get lost, so the PXM never gets the information that the port has become active. The problem has been fixed by increasing the value of the alarm integration timer to 5 secs. This is done by changing the value of gu32TimeoutValue in the code.this timer prevents the channels from going into alarm for the duration of the timer even after the port fails. This is also a fix for CSCdv90898, but for that problem it might be required to increase the above value in shellconn depending on the cpe device.

CSCdu24006

Symptom: Non-Existing connections are displayed on AUSM cards

Condition: MGX:8250 AUSM: 10.0.22 PXM 1.1.33Ak

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 problem 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, e.g.

-> 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.

CSCdu28072

Symptom: The command dspcd shows channel failure even though connections does not exists on the card.

Conditions: This happens if before deleting the last connection on a card, that channel had an alarm on it.

Workaround: Delete the port and line on which that channel was present and re-add the port/line back.

CSCdu29422

Symptom: Trap Manager doesn't get deleted from the standby

Condition:

XM Ver: 1.1.33Al Trap Managers are added, this gets updated on standby too. On Aging, they are deleted only on the Active Card and not on the Standby. (on switchcc, Trap Managers are seen as Enabled inspite on aging.)

Workaround: Not Known.

CSCdu29788

Symptom: Cannot configure line type on FRSM 2E3 other than G.751.

Conditions: MGX:8250 PXM:1.1.33Al FRSM-2E3.

Workaround: Under Investigation.

CSCdu34346

Condition:

Issue the 'addred <primary> <secondary> 2' command. The primary and secondary RPM cards should have different (number or type) of backcards.This condition also applies to the case when each card has one backcard each, both of the same type, but in different slots.

Result:

The following warning is to be expected----

addred:Prim and Sec LineModule type Mismatch. Command will proceed for the card type.

CSCdu37806

Symptom: The command xcnfln -lpb 3 is not supported on FRSM-HS2

Conditions: Always.

Workaround: None.

CSCdu39150

Symptom: The command dspchancnt 2000 gives an error message on FRSM-2CT3

Conditions: MGX 8230/8250 FRSM-VHS card has channel number 2000 enabled.

Workaround: None.

CSCdu42117

Symptom: The dsplog has a message that says "Unable to config requested clock source because clock source 8 is unknown."

Conditions: This message will be seen when the clock source or the node changes.

Workaround: None.

CSCdu42490

Symptom: After MGX1 Power On boot, dspclkinfo shows StratumLevel = none. If the PXM1 back card is UI-S3, StratumLevel should be 3 or if the back card is UI, it should be 4.

Condition: MGX1 Power On boot.

Workaround: After MGX1 Power On boot, program: cnfclklevel = 3 for UI-S3 back card cnfclklevel = 4 for UI back card.

CSCdu43261

Symptom: AUSM does not display line alarm information correctly.

Conditions: When the T1 interface is shut from the 3810.

Workaround: None.

CSCdu43980

Symptom: The Qdepth range is shown incorrectly on AUSM card.

Conditions: MGX:8250 AUSM 8T1/E1.

Workaround: Use valid values from 33 to 16000.

CSCdu45583

Symptom: Slot #30 that was covering for Slot #28 rebooted.

Conditions: After a switchcc on the PXM while secondary card is covering primary card. Need to have two IMA ports on this card connected with a cisco 3660 router.

Workaround: Softswitch back to primary before switchcc.

Further Problem Description: The problem only happens with IMA configuration.

CSCdu51929

Symptom: After External Reference is lost, Stratum3 clock controller on UI-S3, PXM1 back card may not go into Holdover mode or Internal Free Run.

Condition: Cable removed from CLK1 or external clock reference signal loss.

Workaround for Rls up to and including 1.1.34: No need, if external reference is restored. Stratum3 clock controller will lock back to the external reference automatically.

If external reference is lost permanently, clock controller should be reprogrammed to be Stratum4 by executing CLI command cnfclklevel=4 and selecting INBAND reference from a feeder trunk.

CSCdu54264

Symptom: The command switchapsln s x does not work.

Conditions: APS configured.

Workaround: None.

CSCdu54804

Symptom: Wrong ChanConnPCR value displayed after xcnfcha.

Conditions: Always.

Workaround: None.

CSCdu55116

Symptom: The command dspchstats will not work on a FRSM-VHSHS2 card. When executed a unknown command response is returned. The command is listed in the help menu.

Conditions: 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.

CSCdu58229

Symptom: APS switches working to protect on the BXM side but not on the PXM side.

Conditions: BPX APS configured as Bidirectional, Nonrevertive and the remote node is Pop1 PXM with the same APS configuration. There is a following sequence of events: 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 APS lock on the PXM and do a APS clear.

CSCdu61609

Symptom: CiscoView shows inconsistent status for lines in 1:1 FRSM-2T3 in MGX 8250

Conditions: 1:1 red. between cards

Workaround: None.

Further Problem Description: When FRSM-VHS cards are configured for 1:1 Hotstandby redundancy, the standby card's database will be in sync with the primary card's database. If the lines on the Active card are enabled, then snmpget for the same lines on the standby card returns them as enabled. The line LED's on the standby card will show no color, as the lines are not made ready to handle traffic since the card is in standby state.

CSCdu62613

Symptom: On BXM, clearing request APS Force W->P switches the active line to Working.

Conditions: APS 1+1, Bidirectional nonrevertive. BXM connected to PXM. In Sequence Both nodes start on Protect with no requests On PXM, Manual P->W On BXM, Force W->P On BXM, Clear requests

Workaround: Clear any request on PXM before issuing a request on the BXM.

CSCdu63090

Symptom: Input rate less than EIR but 'dspchancnt' shows frames discarded due to UPC.

Also, 'RcvFramesDiscUPC' and 'FramesDiscXceedDEThresh' did not sum to the total discarded frames.

Condition: Happened on FRSM-VHS cards when EIR > Input rate > PIR.

Workaround: Unknown.

CSCdu63686

Symptom: The portM32EgressQueThresh is not preset in the.CF file. This impacts CWM.

Conditions: TFTP of .CF file.

Workaround: None.

CSCdu66317

Symptom: Trap 50609 was received with a invalid failure code.

Conditions: Unknown.

Workaround: None

Further Problem Description:

CSCdu66738

Symptom: Trap 50041 coreCardsPeerMismatch received with invalid shelfSlotNum.

Conditions: When there is core card mismatch.

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.

CSCdu67938

Symptom: Trap 50350: LineEnabled received with an extra varbind.

Conditions: A line was enabled on an AUSM card running 10.0.11 on a node running PXM 1.1.34.

Workaround: None.

CSCdu68044

Symptom: ds1 stays in alarm along with the ports on it.

Conditions: Adding softloop on ds1 w/o soft/hard loop on ds3 holds ds1 & ports in alarm.

Workaround: None

Further Problem Description: After Executing 'addlnloop <ds1>' without soft/hard loop on ds3 on a FRSMVHS-2CT3 card, the ds1 stays in alarm along with the ports on it. Executing 'addds3loop <ds3>' clears the port alarms but not the ds1.

Ds1 and Ds3 Loop should be independent of each other. We are keeping addition/deletion of ds1 loop independent of the state of the ds3 loop.

CSCdu68068

Symptom: CLI commands display the same info for ratio queue vs. weighted fair.

Condition: On both the dspegrq, and the cnfegrq commands.

Workaround: None.

CSCdu68073

Symptom: The xcnfalmcnt command accepts any parameters and does not display any error messages.

Conditions: When xcnfalmcnt command is executed with invalid parameters.

Workaround: None.

CSCdu68402

Symptom: Conditions: Workaround: Further Description: This is a bug opened to resolve all errors found by running the PREFIX utility on the MGXPXM12 baseline

CSCdu72190

Symptom: Active PXM reset due to 'Software Error Reset'. Standby PXM took over. There is no service impact.

Conditions: When CiscoView is running and SRM T3 lines are enabled. The time it takes for the PXM to reset depends on 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.

CSCdu74747

Symptom: Sometimes, while adding a new connection, ports are not showing up in the selection window properly in spite of their being present in the database. For example if the database has 4 ports for a card and shelf, it shows up only two of them or it does not show any.

Conditions: It is intermittent and highly random.

Workaround: Hit Cancel button so that the new connection window disappears. And restart the configure new connection window from connection manager gui. On the MGX side the problem is not seen if a physical(metallic) loopback is added instead of the soft loopback (through addlnloop).

CSCdu75928

Symptom: PXM E1 ext clock sync not working without the Daughter card.

Conditions: In the absence of the Daughter card or Back card, the External E1 clock will not sync and the clock status update would fail.

Workaround: None.

CSCdu76964

Symptom: When the CESM8T1E1 is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.

Conditions: Occurs when the SM is in standby mode.

Workaround: None.

CSCdu76974

Symptom: When the SM is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.

Conditions: Occurs when the SM is in standby mode.

Workaround: None.

CSCdu76975

Symptom: When the SM is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.

Conditions: Occurs when the SM is in standby mode.

Workaround: None.

CSCdu77367

Symptom:

Conditions:

Workaround: Before using the connections, it is advised to do node resync with the feeder nodes first. But if the connections are bouncing, this manual node resync may not help either.

CSCdu79008

Symptom: T1 alarm counters are missing.

Conditions: FRSM-8T1E1.

Workaround: None.

CSCdu83011

Symptom: Misleading message when trying to do softswitch. a warning message of 'possible red table corruption' might lead to confusion.

Conditions: When redundancy card is cover card A and trying to softswitch from card B to redundant card.

Workaround: None. No actual impact.

CSCdu84628

Symptom: In 1+1 bidirectional mode, local manual switch preempts remote manual switch request.

Conditions: Workaround: None.

CSCdu84643

Symptom: In 1+1 uni/bidirectional APS, forced switch of p->w preempts forced switch of w->p

Conditions: Workaround: None.

CSCdu85051

Symptom: In 1+1 bidirectional APS, lockout of protection not blocked by remote lockout of protection.

Conditions: Workaround: None.

CSCdu85063

Symptom: In 1+1 uni/bidirectional APS, manual switch of p->w preempts manual switch of w->p.

Conditions: Workaround: None.

CSCdu86599

Symptom: On a 8 port CESM (AX-CESM-8T1) for the MGX 8220,

it is not possible to configure a line for ESF framing with AMI line coding. This is a valid configuration, and is possible on a 4 port CESM.

Conditions: The problem is observed when configuring

a T1 line. Example: xcnfln -ds1 1 -e 3 -lt 1 -lc 4 This appears to effect all current versions (at least up to 5.0.14) of 8 port CESM cards. 4 port cards operate as desired.

Workaround: Only known workaround is to use a different

configuration or 4 port CESMs.

CSCdu88301

Symptom: On an FRSM-HS1/B card, when traffic in excess of CIR is pumped from the network side, it causes Egress buffer overflow, which in turn causes the card to reset. Egress data buffer overflow can be checked by using the shellConn command SarShow on the FRSM-HS1/B.

Conditions: This happens only on the FRSM-HS1/B version 10.0.22.

Workaround: An upgrade of the FRSM-HS1/B firmware to 10.0.23.

CSCdu88914

Symptom: Not able to add channel with a error 'no more lcn available'.

Conditions: Corruption in resource partition type

Workaround: Use shell command to force update from service module to PXM.

CSCdv02276

Symptom: Primary card in failed state after softswitch

Conditions: Setup: PXM is running 1.1.34 2 AUSM's in 1:N Redundancy & running 10.0.11 version Now we upgrade the AUSM to 10.0.22 by doing a softswitch twice.

Problem: When doing the softswitch from secondary to primary when we do dspred we can see that the primary gets stuck in failed state.

Workaround: Reset the secondary card before the first softswitch.

CSCdv02328

Symptom dspchans, dspifs show empty table if an abort is done in between upgrade

Condition: Perform an install of 1.1.30 newrev 1.1.30 abort 1.1.30 At this point we lose ifs and chans

Workaround: Here is the workaround for this problem, this should be applied only if an abort is required after the newrev stage during the upgrade. Before executing the abort command execute the following commands: Go to sh in the Active PXM

4. smCardMibVer = 21 /* Change the MIB version from 23 (1.1.30) to 21 (1.1.22 and above) */

5. saveDBToArchive 7, 0 /* Create the archive file for slot 7 (VSM) with the changed MIB Version)

6. upLoadBram 7, 7 /* Write the newly created archive file to the Active and Standby disk database */

7. spmdsparchinfo 7 (on Active PXM and Standby PXM) /* Verify that the MIB version has been changed to 21 */

8. Proceed with abort.

If the same shelf is upgrade later on to 1.1.30. After the upgrade is fully completed, execute the following to do cleanup.

Execute the following after the shelf is upgraded to 1.1.30.

1. From sh in the Active PXM.

2. saveDBToArchive 7, 0

3. upLoadBram 7, 7

Further Description: The VSM module in the PXM goes into a mismatch state once we abort at this stage. This causes the SMs to lose ifs and chans (dspifs and dspchans)

CSCdv03072

Symptom: dspclkinfo

****** Clock HW registers ******** SEL_T1 = t1      SEL100 = ON     SEL120 
= ON     SEL75 = ON NOEXTCLK = OFF 
priMuxClockSource = INBAND_CLK1 prevPriMuxClockSource = INBAND_CLK1 
primaryInbandClockSourceLineNum = 1 secMuxClockSource = INTERNAL_OSC 
prevSecMuxClockSource = none secondaryInbandClockSourceLineNumber = 1 
currentClockSetReq = primary currentClockHwStat = primary StratumLevel  = 
STRATUM4 PreviousClockHwStat = primary extClockPresent = Yes 
extClkConnectorType = RJ45 extClkSrcImpedance = 100 Ohms Internal Clock 
Status=255, Primary Clock Status=0 
Secondary Clock Status=0, Last inband Clock State=0 last Inband Clock 
state= 0, Last External Clock Present = 2 
h1a.1.7.PXM.a > dspclksrc Interface    Clock Type     Clock Source 
---------    ----------     ------------ 7.1          PRI           
INTERFACE 
h1a.1.7.PXM.a > cnfclklevel 3 
h1a.1.7.PXM.a > dspclkinfo 
****** Clock HW registers ******** SEL_T1 = t1      SEL100 = ON     SEL120 
= ON     SEL75 = ON NOEXTCLK = OFF 
priMuxClockSource = INBAND_CLK1 prevPriMuxClockSource = INBAND_CLK1 
primaryInbandClockSourceLineNum = 1 secMuxClockSource = INTERNAL_OSC 
prevSecMuxClockSource = none secondaryInbandClockSourceLineNumber = 1 
currentClockSetReq = primary currentClockHwStat = primary StratumLevel  = 
STRATUM4 PreviousClockHwStat = primary extClockPresent = Yes 
extClkConnectorType = RJ45 extClkSrcImpedance = 100 Ohms Internal Clock 
Status=255, Primary Clock Status=0 
Secondary Clock Status=0, Last inband Clock State=0 last Inband Clock 
state= 0, Last External Clock Present = 2 :wq 

Conditions:

Workaround:

CSCdv04213

Symptom: Both primary and secondary cards in active state.

1. Secondary card locked. Unable to cc to the card.

2. Line on CESM T3 generates alarms.

Conditions: To recreate the problem:'

1. softswitch' from primary(active) to secondary(stdby)

2. Then, reset active (secondary).

Workaround: Unknown.

CSCdv08621

Symptom: IP connectivity to the MGX1 node stops working after sometime.

Conditions: IP connectivity is via a PVC configured between an UNI port and 7.34 on the PXM.

Workaround: Delete the connection and readd it.

CSCdv09537

Symptom: R_AM on protection line

Condition: Create LOS on protection, clear it and then create LOS on working.

Workaround:

CSCdv13383

Symptom: Protection line status shows OK while remote SF condition on protection line exists.

Condition: 1+1 bidirectional APS configured.

Workaround: None.

CSCdv13391

Symptom: Late local equal priority request is selected in generating TxK1 after remote equal priority request is being acknowledged by PXM.

Condition: 1+1 bidirectional APS configured.

Workaround: None.

CSCdv13400

Symptom: PXM selects protection line and shows CH_MIS even though there is SF condition on remote BPX.

Condition: 1+1 bidirectional APS configured.

Workaround: None.

CSCdv15625

Symptom: When we do addlnloop on the srme card the alarms are still there. Basically the command does not work.

Conditions: *)add line on srme oc3 card, addlnlloop on the srme line *)add a line in one of the SM's say FRSM on slot 1 line 1 *) addlink between slot1 line 1 to srme line. we can see that the line is still in alarm actually it should not be in alarm

Workaround: The problem is because of hardware limitation. Supermapper chip has a version 2.0 which does not support the addlnloop. The newer version i.e., 2.1 or above supports addlnloop command. If we upgrade the supermapper to newer version then we should not see this problem.

CSCdv25524

Symptom: The SNMP agent receives values 15, 16 and 17 for function module state which are not defined in the MIB.

Conditions: When the card goes to CardInit state while booting up, the SRM card fails.

Workaround: None.

Further Problem Description: After the fix, state representing 15 and 16 have been removed. 17 has been defined as cardinit. That way when the old PXM image sends 17, the new SNMP agent will understand it properly.

CSCdv26309

Symptom:

Connection configured on FRSM 8E1 on an MGX 8250 unabled to be deleted due to error "Port does not exist". Port is well configured and has other connections already configured and passing traffic. Also further connections cannot be added to he logical port 248 as same response is returned. Connections successfully added and deleted on other logical ports of the same card without problem/errs.

Conditions:

MGX 8250 dspfwrevs

Card Type   Date       Time     Size     Version             File Name
 ----------- ------------------- -------- ------------------- 
------------------ 
PXM1        08/02/2001 18:10:22 1301128  1.1.32         pxm_bkup_1.1.32.fw 
PXM1        08/02/2001 18:29:20 2241996  1.1.32              pxm_1.1.32.fw 
FRSM-8T1E1  08/02/2001 20:48:20 297988   FR8_BT_1.0.02       sm35.bt 
FRSM-8T1E1  08/02/2001 20:55:46 821064   10.0.21             sm35.fw 

Workaround: No workaround found, switchcc had no effect.

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 session.

Workaround: Run extended pings from telnet sessions instead of cc to the card

CSCdv29944

Symptom: Link addition on standby card successful.

Condition: Add redundant back card and then add link on this.

Workaround: None

CSCdv31953

Symptom: Unable to collect all stat types from CESM

Conditions: Customer enabled all stat types on CESM. Connection Stats for CESM(CE Connection)

Object          SubObjectId       Statid          Stat Description(as 
shown in GUI) 
0                10                16                Seconds In Service 0                
10                58                AAL1 Sequence Mismatch 0                
10                60                Receive Bytes Discarded 0                
10                62                Rx Buffer Underflows 0                
10                63                Rx Buffer Overflows 0                
10                64                HCS Correctable Error 0                
10                65                Loss of Pointer 0                10                
66                Loss of Cell Delineation 0                10                
69                Tx Bytes Discarded-Q-Overflow 0                10                
70                Tx Cells Inserted-Q-Underflow 0                10                
71                Total Cells Tx to Line 0                10                
72                Total Cells Rx to Line 
But only be able to get stats on AAL1 Sequence Mismatch HCS Correctable 
Error Loss of Cell Delineation Total Cells Tx to Line Total Cells Rx to 
Line 

Workaround: Under Investigation.

Further Problem Description: Under Investigation.

CSCdv33089

Symptom: Link/Line configuration is not deleted on srme after clrsrmcnf.

Condition: Configure link.

Workaround: None.

CSCdv35890

Symptom: SRM-E stat files are bad intermittently.

Condition: The node is synced up and used integrated SCM for collecting; only SRM-E Sonet line stats are enabled.

Workaround: Not known.

CSCdv37960

Symptom: PXM locks onto a bad clock added as a primary clock.

Conditions: When PXM-UI-S3 back-card is used and clock level is Stratum 3.

Workaround: Use the internal oscillator of the UI-S3 back card.

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 MGX 8250 FRSM code from 10.0.20 to 10.0.22.

Workaround: None, unless chanservtype has already been selected other than default to ABR servicetype.

CSCdv39679

Symptom: PXM does not try to lock onto the secondary clock.

Conditions: When PXM-UI-S3 back-card is used and clock level is Stratum 3 and primary clock has failed for some reason.

Workaround: Use the primary clock or the internal oscillator of the UI-S3 back card.

CSCdv43539

Symptom: Card not in alarm when line is.

Conditions: One or more lines on V.35 interface are in major alarm.

Workaround: Issue IntegrateCardAlarm(2,256,37) from shellConn.

CSCdv45481

Symptom: Occurs when dsplns, dspalm, dspcd is used.

Conditions:

1. When the line moves from major alarm to minor alarm, dspalm indicates the line in the appropriate alarm, but dspcd will still be at major alarm and does not get updated to minor alarm. Vice versa is also true.

2. When delds3loop is executed on a line which does not have a loop configured, card alarm is cleared if the alarm was because of this line and even though the line is still in alarm.

Workaround: None.

CSCdv47050

Symptom: The command xcnfalm syntax shows -ds1 <line> instead of -x21 <line>.

Conditions: Get help on xcnfalm command.

Workaround: None.

CSCdv47076

Symptom: The command xcnfport syntax doesn't show -sig option.

Condition: Get help on xcnfport.

Workaround: None.

CSCdv47086

Symptom: The command xcnfport syntax description shows unwanted options

Conditions: Issuing xcnfport with no or illegal parameters

Workaround: None.

CSCdv48190

Symptom: Connection doesn't go into failed state on PXM upon subinterface admin shutdown

Condition: When the subinterface is administratively shutdown, the connection under that subinterfaces should go into fail state or at least a failure trap should be sent to indicate no routing can take place. CWM was not getting this Failure trap.

Workaround: None.

CSCdv49617

Symptom: Output of dspapsln is not aligned between the header and APS line status.

Conditions: Workaround: None.

CSCdv51362

Symptom: Not able to configure bert for lines greater than 8.

Condition: Unknown.

Workaround: Unknown.

CSCdv53166

Symptom: The clock status is inconsistent between dspcurclk and dspclkinfo.

Conditions: When all of the following are true:

1. PXM-UI-S3 back-card is used and clock level is Stratum 3.

2. There is a clock-switch from primary due to an bad (incorrect frequency) clock source.

3. There is no Loss Of Action on primary clock interface.

Workaround: Use dspclkinfo to find the status of the clock.

CSCdv53181

Symptom: PXM does not track a good SERVICE MODULE interface clock.

Conditions: When PXM-UI-S3 back-card is used and clock level is Stratum 3 and the active clock source is SERVICE MODULE.

Workaround: Use the external clock source, inband or internal oscillator of the UI-S3 back card.

CSCdv56345

Symptom: With many ports added on a FRSM-VHS (FRSM-2CT3), addport may fail due to insufficient hardware resources for further ports. However, the display does not show this as the reason.

Conditions: On the FRSM-VHS (e.g., FRSM-2CT3) there is a limit of 128 ports for each of - ds1 1-14,43-56 - ds1 15-42

When adding a port that exceeds this limit, the error message does not accurately indicate the cause of the failure.

Workaround: There is no workaround, this is a limitation of the hardware. The bug is that the display does not give an appropriate error message.

CSCdv69785

Symptom: Remote Loopback operation is not blocked by CiscoView on a AUSM 8T1 line while the line is being added.

Conditions: Add a remote loopback on AUSM8T1, the remote loopback takes effect inspite of an error message.

Workaround: None.

CSCdv73784

Symptom: PXM reset due to LOG task suspension

Conditions: Unknown.

Workaround: None. Standby PXM will take over and become active.

CSCdv76611

Symptom: Line with soft loop does not go into minor alarm.

Conditions: Line is added on FRSM-HS2/B using CV with a soft loop. Line is added but does not go into a minor alarms. If the line is modified using CV then it goes into minor alarm.

Workaround: Modify the line using Cisco View OR add line using CLI.

CSCdv76770

Symptom: PXM has a corrupted file system and the card gets reset sometimes

Conditions: When CWM does a saveallcnf and then renames the file to the same file using different fashion

Workaround: Switchcc to the standby PXM and format the corrupted PXM.

Further Problem Description: Customer is using the CWM saveallcnf script to save config. However, due to the vxwork rename limitation. The script will trigger the problem by renaming the file to the same file. Hence, the PXM file system is corrupted and needs to be formatted to clean up.

CSCdv85789

Symptom: Voice calls dropped on a softswitch on ausm.

Conditions: This happens mostly for channels on an IMA group.

Workaround: None

Further Problem Description: This happens because the IMA groups restart on a softswitch as the t1 lines are reprogrammed for the standby going active.

CSCdw07261

Symptom: Channel alarms are not propagated after deleting one end of the connection.

Conditions: CESM-T3/E3 PXM:1.1.41Ac.

Workaround: Under Investigation.

CSCdw07565

Symptom: PXM OC-3 ports (UNI) do not go into alarm when the line is fed Sonet PATH AIS from tester.

Condition: HP Tester is connected to PXM-1 OC-3 port and Sonet AIS-P cells are injected. Line reports alarm, but, port remains active.

Workaround: Unknown.


Related Documentation

Note that for Release 1.2, 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.2.23.

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

Product documentation for VISM 3.0 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/vism30
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/vism30
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/vism30

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 Documentation 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.


Note Starting in April 2003, the documents listed in the "Related Documentation" section will be available online only.


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.