Guest

Cisco MGX 8250 Software

1.1.42 Version Software Release Notes Cisco WAN MGX 8850, 8230, and 8250 Software

 Feedback

Table Of Contents

Release Notes for Cisco WAN MGX 8850 Release 1, MGX 8250, and MGX 8230 Software Version 1.1.42

Contents

About These Release Notes

Features Introduced in Release 1.1.42

Features Introduced in Release 1.1.41

VISM Release 2.2 on MGX 8850 Release 1, MGX 8250, and MGX8230 Switches

Features Not Supported in This Release

MGX 8220 Hardware Superseded by MGX 8850-Specific Hardware

Redundancy Support

Network Management Features

Port/Connection Limits

SNMP MIB

Notes and Cautions

Stratum-3 Clocking

UPC Connection Parameters

ForeSight and Standard ABR Coexistence Guidelines

CLI Modifications in Release 1.1.4x

Node Related

Connection Management Related

RPM Related

RPM Front Card Resets on the Back Card Removal

RPM-PR Back Ethernet Card Support

RPM/B Ethernet Back Card Support

Limitations

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

clrsmcnf

Problems Fixed in Release 1.1.42

Problems Fixed in Release 1.1.41

Known Anomalies for Platform Software Release 1.1.42 and Service Module Firmware

Compatibility Notes

MGX 8230, MGX 8250, and MGX 8850 Software Interoperability with Other Products

Boot File Names and Sizes

VISM and RPM Firmware Compatibility

MGX 8250 and MGX 8850 Firmware Compatibility

MGX 8230 Firmware Compatibility

Comparison Matrix

RPM Compatibility Matrix

Special Installation and Upgrade Requirements

Special Instructions for Networks Containing FRSM 2 CT3

Executing the Script

Script Functionality

Single PXM Installation Procedure

Installation Procedure for Redundant PXMs

Instructions to Abort PXM Upgrade

Upgrade from Release 1.1.3x

Upgrade from Release 1.1.2x

Service Module Boot/Firmware Download Procedure

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 8850 Switches

Service Module Upgrades

Route Processor Module (RPM) Addendum

About the CISCO IOS 12.2(4)T1 Release

About the Cisco IOS 12.2(4)T Release

About the Cisco IOS 12.2(2)T2 and 12.2(2)T3 Release

About the Cisco IOS 12.1(5.3)T_XT Release

Problems Fixed with IOS 12.1(5.3)T_XT

Bypass Feature for RPM in 12.2(4)T IOS Release

Upgrading from an RPM/B Card to an RPM-PR Card

Booting the RPM

RPM Bootflash Precautions

Upgrading with 1:N Redundancy

Upgrading Non-redundant RPM-PR Cards

Historical Information from the 1.1.4x Baseline

Features Introduced in Release 1.1.40

16,000 Connections

RPM Multi LVC

ITU APS

RPM (RPMB/RPM-PR) 1:N

VISM Release 2.1(0) and Release 2.1(1) on MGX 8850 Release 1, MGX 8250, and MGX 8230

Problems Fixed in Release 1.1.40

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center


Release Notes for Cisco WAN MGX 8850 Release 1, MGX 8250, and MGX 8230 Software Version 1.1.42


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.1.42, the user documentation (command reference, overview, and installation and configuration guides) were not updated. Use the Release 1.1.3 documents in addition to this release note.

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 2.2 is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/vism22
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/vism22
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/vism22

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.1.42

Release 1.1.42 is a maintenance release that supports all new features introduced in Release 1.1.40. (See "Features Introduced in Release 1.1.40" section.)

Features Introduced in Release 1.1.41

Release 1.1.41 was a maintenance release that supported all new features introduced in Release 1.1.40. (See "Features Introduced in Release 1.1.40" section.)

VISM Release 2.2 on MGX 8850 Release 1, MGX 8250, and MGX8230 Switches

Refer to the Release Notes for Cisco Voice Interworking Service Module Release 2.2(0) for information about VISM features, upgrade instructions, and anomalies. Product documentation for VISM Release2.2 is available at the following URLs:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/vism22

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/vism22

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/vism22

Features Not Supported in This Release

MPLS inter AS, MPLS TE, and POS port-adapter are not supported features on RPM.

S3 clocking

Layer 2 support as an AutoRoute routing node

SRM T1E1

Bulk distribution with the SRM cards for E1 circuits

Interworking with Cisco 3810

MGX 8220 Hardware 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-A front card and the MGX-BNC-3T3 back card replaces the original AX-BNC-3T3 back card. Both the AX-SRM-3T3-A/AX-BNC-3T3 card set and the MGX-SRM-3T3-C/MGX-BNC-3T3 card set are supported on the MGX 8220.

The AX-SCSI2-2HSSI is superseded by the MGX-SCSCI2-2HSSI/B, which works with the MGX-FRSM-HS2 front card. A V.35 interface is supported on the MGX-FRSM-HS1/B in this release.

Redundancy Support

MGX 8850 provides high-speed native ATM interfaces that 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-2T3E3

1:1 redundancy

AX-FRSM-8E1

1:N redundancy

AX-FRSM-8E1-C

1:N redundancy

AX-FRSM-8T1

1:N redundancy

AX-FRSM-8T1-C

1:N redundancy

MGX-FRSM-HS2

1:1 redundancy

MGX-FRSM-2CT3

1:1 redundancy

MGX-FRSM-2T3E3

1:1 redundancy

MGX-FRSM-HS1/B

No redundancy

MGX-RPM-128M/B

1:N redundancy

MGX-RPM-PR-256

1:N redundancy

MGX-RPM-PR-512

1:N redundancy

MGX-VISM-8T1

1:N redundancy

MGX-VISM-8E1

1:N redundancy

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


Bulk distribution is supported for T1 lines only on the SRM-3T3 card.

Network Management Features

Network management features are detailed in the CWM Release 10.5 release notes at: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm

Port/Connection Limits

Connection limits can vary. The table below shows total connections per card, but also shows the number of connections per port with LMI enabled. For example, the FRSM-HS2 card using an 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.

See 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

HSSI

2000

2

2

560

898

MGX-FRSM-2CT3

BNC-2T3

4000

2

256

560

898

MGX-FRSM-2T3E3

BNC-2T3

2000

2

2

560

898

 

BNC-2E3

2000

2

2

560

898

 

BNC-2E3A

2000

2

2

560

898

MGX-FRSM-HS1/B

12IN1-4S

200

4

4

200

200

MGX-AUSM-8E1/B

RJ48-8E1

1000

8

8

 

SMB E1

1000

8

8

MGX-AUSM-8T1/B

RJ48-8T1

1000

8

8

AX-CESM-8E1

RJ48-8E1

248

8

248

 

SMB-8E1

248

8

248

AX-CESM-8T1

RJ48-T1

192

8

192

MGX-CESM-2T3E3

BNC-2T3

1

1

1

 

BNC-2E3

1

1

1

AX-FRSM-8E1

RJ48-8E1

1000

8

8

560

898

 

SMB-8E1

1000

8

8

560

898

AX-FRSM-8E1-C

RJ48-8E1

1000

8

192

560

898

 

SMB-8E1

1000

8

192

560

898

AX-FRSM-8T1

RJ48-8T1

1000

8

8

560

898

AX-FRSM-8T1-C

RJ48-8T1

1000

8

192

560

898


For the 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 SNMP MGX Release 1 MIB are provided with the delivery of this release. The MIB is in standard ASN.1 format and is located in the same directory within the release bundle on CCO. These files may be compiled with most standards-based MIB compilers. The tar file for MIB contains the file release notes that contains the MIB release notes.

For changes in this MIB from the previous release, please refer to the MIB release notes.

Their are two formats contained in the bundle:

old_mibFormat

new_mibFormat


Note The old_mibFormat will be discontinued in a future release.


Notes and Cautions

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

Stratum-3 Clocking

The PXM-UI-S3 back card used in previous releases to support Stratum-3 level clocking, is not supported in the Release 1.1.x baseline.

UPC Connection Parameters

In Release 1.1.40, Release 1.1.41, and Release 1.1.42, 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.

Depending upon your connection type, you can use the following command line interface (CLI) commands to modify the PCR parameter.

cnfupccbr

cnfupcvbr

cnfupcabr

cnfupcubr

ForeSight and Standard ABR Coexistence Guidelines

ForeSight is similar to the rate-based ABR control system in TM 4.0 in that they both use Rate up and Rate down messages sent to the source of the connection to control the rate a connection runs at, based on congestion within the switches along that connections path. Both systems use Resource Management (RM) cells to pass these messages. There are differences between the two systems that need to be considered.

RM Cell Generation

ForeSight is a destination-driven congestion notification mechanism. The destination switch is responsible for generating the RM cells, which defaults to every 100 ms. This means that any rate modifications at the source end happen approximately every 100 ms, and the time delay between the actual congestion at the destination and the source getting to know about it could be 100 ms.

In standard ABR a source generates FRM cells every (nRM) cell intervals, where n is configurable. These are used to pass congestion information along to the destination switch, which then uses this information to generate BRM (Backward RM) cells back to the source A further consideration is that the actual user data flow will be lower for an equivalent rate due to the additional RM cells. Therefore, the more traffic being generated on a connection at any one time, the faster the feedback will be to the source.

There is also a TRM parameter which states that if no RM cells have been generated after this time has passed then one will automatically be sent. Depending upon the speed it is running at, an ABR connection may therefore react faster or slower to congestion than the equivalent ForeSight connection. (for example, if an ABR connection runs at 100 cells per second, and nRM is 32, then approximately three RM cells will be generated per second, or once every 300 msecs. If it runs at 1000 cps then an RM cell would be generated approximately every 30 msecs. In both cases, the equivalent ForeSight connection would generate an RM cell every 100 msec.)

Reaction to Feedback Messages—Rate Up

In ForeSight, in response to a Rate Up cell from the destination, the source increases its rate by a percentage of the MIR for that connection. If we call this percentage the rate increase percentage (RIP), then RIP is configurable at the card level (the default is 10 percent). In the case where MIR is low, the ForeSight rate increase will be slow as it has to increase as a percentage of MIR (rather than CIR).

On a standard ABR connection, in the event of available bandwidth (no congestion) the source increases its rate by a factor of (RIF*PCR). This means the rate increase step sizes are much bigger than for ForeSight for larger values of RIF (RIF has a range of 1/2, 1/4,....,1/32768). If RIF is not configured properly then standard ABR will ramp up its rate much faster and to a higher value. This is aided by the fact that the step sizes are bigger and the step frequency is higher in comparison with ForeSight.

Reaction to Feedback Messages—Rate Down

In ForeSight on receiving a Rate Down cell from the remote end, the source reduces its current rate (actual cell rate) by 13 percent. The rate decrease percentage (RDP). RDP is configurable at the card level.

In standard ABR, rate decrease is by an amount (RDF*ACR). Currently, the default value of RDF is 1/16 (6.25 percent). This means when this connection co-exists with ForeSight connections, in the event of congestion ForeSight connection reduces its rate by 13 percent whereas standard ABR connection reduces its rate by only 6.25 percent. Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types, then RDF should be changed to 1/8, so that both connections ramp down by the same amount (13 percent).

Fast-Down

In ForeSight if the destination egress port drops any data due to congestion then the destination sends a Fast Rate Down cell. Also, if a frame cannot be reassembled at the egress due to a lost cell somewhere in the network, a Fast-down will be generated. On reception of Fast Rate Down the source reduces its current rate by 50 percent (this is again a card-level configurable parameter).

Standard ABR does not distinguish between drops and the ECN/EFCI threshold being exceeded. This means that, in case of drops in the egress port queue, a standard ABR connection rate reduces by only (RDF*ACR) but the ForeSight connection rate reduces by (ACR*0.5). Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types then Fast Down could be effectively disabled by configuring the reaction to be 13 percent rate down instead of 50 percent.

Guidelines

The two systems will work together within the network, but as the above description suggests, if the differences between the two systems are not taken into consideration, then a ForeSight connection and an ABR connection with the same configuration parameters will not behave the same way within the network.

ABR and ForeSight provide a mechanism for distributing excess bandwidth between connections over and above the minimum rate, therefore if these guidelines are not taken into consideration then the allocation of this excess bandwidth may be biased toward connections running one of these algorithms over connections running the other.

If this is a requirement, the following guidelines may be useful, assuming ForeSight is set to defaults except for Fast Rate Down which is set for 13 percent.

1. Nrm: Nrm needs to be set at a value whereby the approximate RM cell generation is
100 milliseconds, to match that of ForeSight. This calculation is based on the expected average, or sustained, cell rate of the connection. However, if the (potential) fast-down messages from ForeSight are left to equate to 50 percent rate down, then an estimate of how often this may occur needs to be made and factored into the equation. If the connection receives Fast-down messages, then this would make the ForeSight connection react faster than the equivalent ABR connection to congestion. To compensate for this, Nrm needs to be set at a value of less than 100 msecs, a suggested value to aim for is between 60-70 msecs (this would be approximate as n is configurable in steps of 2**n). This would mean that, in the event of congestion, the ABR connection would start to react faster.

2. RIF: Rate increase factor is a factor of PCR in ABR and MCR in ForeSight. The default RIF for ForeSight is MCR*.10. Therefore, RIF should be configured so that (PCR*RIF) approximates MCR*0.1. If Fast-Down is still effectively enabled, then PCR*RIF should approximate MCR*0.62 to compensate.

3. RDF: (Rate Decrease Factor) RDF should be 1/8. This approximates to 13 percent that ForeSight uses.

The following worked examples may help explain this further

Assume a network is currently running ForeSight with default parameters, and supports the following four connection type, where CIR = MIR, PIR = port speed, and QIR = PIR:

T1 Port Speed 64K CIR

Example:

CIR = MIR = 64K
PIR = QIR = port speed = 1544
Fastdown = 13%

(The calculation used to convert between frame based parameters [CIR, PIR, and so on] and their equivalent cell-based parameters is FR_param *3/800. This allows for cell overheads, and so on, based on frame sizes of 100 octets.)

CIR = MIR = (64000*3/800) = 240 cps
PIR = QIR = (1544 *3/800) = 5790 cps

ForeSight ABR
Rate-up equals (240*.1) = 24 cps RIF equals x where (1590/x) = 24 cps
X needs to be approx 200
RIF equals 256 (nearest factor of 2)

RDF equals 13% RDF = 1/8
Nrm equals 100 msecs Nrm equals 32

RM cells will be generated somewhere between 6 (5790 cps approx equal to 32 cells per 6 msecs) and 133 msecs (240 cps approx equal to 32 cells every 133 msecs) depending on ACR.

CLI Modifications in Release 1.1.4x

Table 3 lists the new and modified commands in Release 1.1.4x baseline.

Table 3 New or Modified CLI Commands in This Release 

CLI
Changes
For Feature

addapsln

The parameter <archmode> sets the APS architect mode to be used on the working/protection line pairs. The new value, 5, is added to specify 5: 1+1 Annex A.

ITU APS Annex-A

dspapsln

Note MIBs changes under the APS Config Group have been added. For more information, refer to the MIB release notes that are part of the MIB tar in the Release 1.1.40 image.

ITU APS Annex-A


Node Related

A maximum of one BERT test can be performed per bay at any point in time. BERT can be activated only through the CLI.

If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in to the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.

To load the correct common boot code image, performed the following procedure on an MGX 8220 chassis, and not on an MGX 8850 chassis. This procedure is also outlined in the Cisco MGX 8850 Installation and Configuration.


Step 1 Enter ftp to port the Axis 5 common boot image for the service module to a workstation.

Step 2 Plug in the card into the MGX 8220 shelf.

Step 3 Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:

tftp <ip address of the MGX 8220 shelf > 
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 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, the 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 the cnfifip command in the Cisco MGX 8850 Command Reference for syntax.


Note The copychan command does not work.


A minimum of two and up to four IP addresses are needed to be configured for MGX 8850 (one or more of the following: Ethernet, ATM, SLIP) and the boot IP address. The user should use bootChange to set up IP gateway when the PXM card is just installed. The IP default gateway should be on the same subnet as the PXM board. Enter the bootChange command to set correct IP address, netmask, and default gateway.

Do not install a Y-cable on the UIA CP port for PXMs. If you do, both serial ports will be enabled and you will not be able to communicate with the shelf through the console ports. If after switchcc the standby PXM loses the down-level port, it is most likely due to a downlevel Beta version of UIA back card that was shipped during field-trial only. Upgrading the UIA back card to the latest version should fix this problem.

To configure the external clock source, use the interface label 7.35. Do not use 0.33 or 7.33.

There are also routeShow/routeAdd/routeDelete commands for modifying routing tables.

You must reboot your PXM after each modification with "bootChange" for it to take effect.

 -> bootChange
   - Only enter the ethernet IP address, netmask and default gateway.
   - Type "." to erase incorrect entries.
     tigers.1.7.PXM.a > bootChange
     '.' = clear field;  '-' = go to previous field;  ^D = quit
     boot device          :lnPci 
     processor number     :0 
     host name            :C             <-- Please put "C".
     file name            :
     inet on ethernet (e) :172.29.37.40:ffffff00  <-- Ethernet IP Addr/Netmask
     inet on backplane (b):
     host inet (h)        :
     gateway inet (g)     :172.29.37.1   <-- Default Gateway
     user (u)             :
     ftp password (pw) (blank = use rsh):
     flags (f)            :0x0 
     target name (tn)     :
     startup script (s)   :
     other (o)            :
   - Type in reboot, after this the command "ping" will work as follows:
     tigers.1.7.PXM.a >ping 171.71.54.53 1
     171.71.54.53 is alive

Service module upgrades error handling is not provided. If the user skips any of the steps during upgrade or if a power failure happens in the middle of the upgrade, results will be unpredictable. See the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.

The MGX 8850 supports 15 simultaneous Telnet sessions and 10 TFTP sessions.

You must use the following Y-cables for FRSM-HS2 and FRSM-CT3 redundancy as specified in the Product Orderability Matrix (Straight Cable: 72-0710-01, Crossover Cable: 72-1265-01, Straight Y-cable: FRSM-HS2: CAB-SCSI2-Y, FRSM-CT3: CAB-T3E3-Y). Other cables are not supported.

Y-cable redundancy for FRSM-HS2, FRSM-2CT3, FRSM-2T3, FRSM-2E3 is supported only for adjacent slots.

There is no need to enter the syncdisk and shutdisk commands before removing the PXMs. The system quiesces the disk by detecting the removal of the PXM board and flushes the write buffers to the disk and puts the PXM in sleep mode. This disables any further hard disk access since it locks the actuator.


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



Caution Cooling and power limitations—Customer should be aware of the need for extra power supplies and fans beyond certain limitations. A single fan tray will support all configurations that draw between 1200W and 1400W. For power requirements, the MGX 8850 requires a minimum of one power supply per line cord to support the power requirement for five cards.

 
0-5 Cards
6-10 Cards
11 and Above

Single Line Cord (N+1):

2

3

4

Dual Line Cord (2N):

2

4

6


This is based on an estimated worst-case power requirement of 190W plus margin per card slot.

Connection Management Related

The name of the node cannot be changed if there are PVCs. The node name must be changed from the default value before adding connections, since it cannot be changed later. Enter the cnfname command to change the node name.

Only one feeder trunk can be configured. No BNI trunk to MGX 8850 as a feeder is supported.

The slave end of a connection must be added first.

The slave end cannot be deleted and re-added back by itself. If you delete the slave end, the entire connection must be completely torn down and re-added back. If the slave end of the connection is deleted and re-added back by itself, then unpredictable results will happen.

For user connections, VCI 3 and VCI 4 on every VPI are reserved for VPC OAMs.

The actual number of feeder connections you can provision on the PXM is always two less than you have configured. The dsprscprtns command shows max connections as 32767, but you can only use 32767 - 2 = 32765. One connection is used for LMI and another one for IP relay.

There is no error handling detection while provisioning through the CLI. Invalid endpoints and unsupported connection types (such as connections between FRSM-CESM ports or connections between structured and unstructured connections) are permitted using the CLI. The user should not configure these connections.

The sum of CIR of all channels of a port can be greater than port speed as long as CAC is disabled. However, it is not acceptable for one channel's CIR to be greater then port speed even if CAC is disabled. Two channels added up can exceed port speed. This means you cannot oversubscribe a port if only one channel is configured.

When trying to add a port on DS0 slot 32 of a CESM-8E1 line using an SNMP set or the CiscoView Equipment Manager, the SNMP agent in CESM will time out, without adding the port. The SNMP libraries treat the 32 bit DS0 slotmap (cesPortDs0ConfigBitMap) as an integer. The value for the last DS0 is treated as the sign value. This causes a corruption in the packet coming to the agent. As the agent does not receive a complete SNMP packet, it does not respond and times out. Use the command line interface to add a port on DS0 slot 32 of a CESM-8E1 line.

The cnfport command does not allow VPI ranges to be reduced. The cnfport command only allows the VPI range to expand. The correct sequence is to delete all connections on the partitions, delete the partitions, delete the port, and add the port with new VPI range.

On an FRSM-2CT3, one can add 128 ports on a group of 14 T1 lines as indicated below.

lines 1 to 14: 128 ports (A)

lines 15 to 28: 128 ports (B)

lines 29 to 42: 128 ports (C)

lines 43 to 56: 128 ports (D)

So, to add 256 ports on one T3: add 128 ports on the first 14 T1 lines and the remaining 128 on the next 14 T1 lines.

Note that (A) and (D) are connected to first FREEDM and (B) and (C) are connected to the second FREEDM. Each FREEDM supports only 128 ports. If 128 ports are added on one T3 as in (A), then there cannot be any more ports as in (D). The 129th port should be on lines 15 to 42 (as in B or C).

If the user adds a connection between an RPM and a PXM and then deletes the connection, the RPM shows no connection but the PXM still has the connection. The MGX was designed and implemented in such a way that only the connections that have the master end show up on PXM (by dspcons command). Consider these three connections:

c1: has only slave end

c2: has only master end

c3: has both master and slave end

When using the dspcons command, c2 and c3 will be displayed, not c1. The connection will not show up once the master end (PXM) is deleted. Recommendation: When adding a connection, if one end of the connection is PXM, always configure the PXM side to be the slave. Thus when deleting the RPM side, which is the master, the connection will not show up on the PXM. However, keep in mind that the slave end (PXM) still exists. This also provides a side benefit. When a connection exists with only the slave side, no bandwidth is occupied. The bandwidth is reserved only if the master end exists (with or without the slave).

The MGX-FRSM-HS1/B is capable of supporting a total throughput (card-level) of 16 Mbps. However, it is possible to configure four lines each supporting up to 8 Mbps, thus oversubscribing the card. This has been raised in bug #CSCdm71476 and a restriction/warning will be added in a future release.

Addlnloop on an FRSM-HS1/B line works only when there is a (valid) cable plugged in to the back card on that line. This is a hardware limitation on the back card and has been mentioned in the Release Notes in bug# CSCdm44993.

RPM Related

The RPM/PR and RPM/B operate under the following IOS and Release 1 software.

MGX SW Version
1.1.3
1.1.32
1.1.34
1.1.40
1.1.41/1.1.42

"Bundled" IOS SW version

12.1(3)T

12.1(5.3)T_XT

12.2(2)T2

12.2(4)T

12.2(4)T1

IOS Version

not supported

12.1(5.3)T_XT

12.2(2)T2

12.2(4)T

12.2(4)T1

CWM

10.3

10.4.01

10.4.01 Patch 1

10.5

10.5


With MGX Release 1.1.32 and later, two Route Processor Modules (RPMs) are supported; the RPM/B and the RPM-PR.

The RPM/B is a NPE-150 based router card capable of sustaining 150,000 pps. The RPM-PR is an NPE-400 based router capable of sustaining over 350,000 pps. The RPM-PR will only operate with IOS 12.1(5.3)T_XT or later. For the following section, RPM refers to both the RPM/B and the RPM-PR (unless specifically called out). Some software versions and limitations are not applicable to the RPM-PR because it does not support IOS versions before 12.1(5.3)T_XT.

With RPM/B versions earlier than 12.O.7T1, some limitations in Inter-Process Communication when the RPM/B is at high loads can cause the PXM to declare that the RPM/B has Failed. To avoid this with RPM/B, software releases earlier than 12.0.7T1, throughput is limited to 62,000 pps, and it is recommended that MPLS configurations are limited to 100 interfaces. With RPM software releases from 12.0.7T1, those limitations are removed. In a separate limitation, the number of directly connected OSPF networks supported by an RPM is currently limited to 27. This means that any or all of the subinterfaces supported by the RPM can run OSPF, but the number of distinct OSPF networks supported is limited to 27. (A work around is available and is discussed below.) The limit of 27 arises because of the overheads of supporting separate link-state databases for separate networks.

In an application where the RPM is a Provider Edge Router in an MPLS Virtual Private Network service, a much better solution in any case is to use a distance-vector routing protocol between the customer routers and the RPM. A distance-vector routing protocol provides exactly the information required for this application: reachability information, and not link-state information. The distance-vector routing protocols supported by the RPM are BGP, RIP v1 and RIP v2, as well as static routing. With RPM software releases from 12.0.7T1, distance-vector routing protocols can be used with as many different networks as subinterfaces.

Note that if the RPM is acting as a Provider Edge Router in an MPLS Virtual Private Network service, and even if OSPF is running in a customer network, it is not necessary to run OSPF between the customer router and the RPM. If the customer edge devices run Cisco IOS, they can redistribute OSPF routing information into RIP using the IOS commands, redistribute RIP in the OSPF configuration, and redistribute OSPF in the RIP configuration. Similar configurations are possible for BGP. (For more information on re advertisement, see the "Configuring IP Routing Protocol-Independent Features" chapter in the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1). Redistribution is not unique to Cisco CPE, and other vendors' equipment also supports redistribution.

RPM Front Card Resets on the Back Card Removal

The RPM front card may reset on an MGX 8250 switch when the ethernet back card is removed or inserted.

This reset problem can be easily avoided if "shut" interface is executed before the removal of the back card.

RPM-PR Back Ethernet Card Support

For Ethernet connectivity with the RPM-PR, the model "/B" four-port Ethernet back card is required (order number: MGX-RJ45-4E/B).

RPM/B Ethernet Back Card Support

The model "/B" four-port Ethernet back card can be used with the MGX-RPM-128M/B module only in combination with IOS 12.2(2)T2 or higher. The model "/B" back card will not work on the MGX-RPM-128M/B with earlier versions of the IOS.

The order number is order number: MGX-RJ45-4E/B.

Older back cards can be used with any version of the IOS.

4-port Ethernet back card used with MGX-RPM-128M/B
Required IOS

model "/B" back card

12.2(2)T2

earlier back card models

Min. IOS for MGX-RPM-128M/B on MGX 8250 is 12.0(7)T


Limitations

CWM Recognition of RPM-PR and 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:

Saving a configuration of an SM from one shelf and restoring it to the same slot on another shelf.

Saving a configuration of an SM in a slot and restoring it to another slot of the same card type.

Problems Fixed in Release 1.1.42

Bug ID
Description

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

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:

Addind/deleting connections on the line will cause the problem regardless if it has been added via CWM or CLI.

Workaround:

None

CSCdw89912

Symptom:

CESM8T1E1 comes up as failed after it boots up.

Conditions:

This occurs after the shelf on which the card is present, is powercycled. This behaviour is intermittent.

Workaround:

Reset the card which is stuck in the failed state.


Problems Fixed in Release 1.1.41

Bug ID
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

CSCds77223

Symptom:

Changing the ingressq to the minimum value of 4510 on a FRSM card causes all traffic to be discarded.

Conditions:

Change of ingressq to the minimum value of 4510

This occurred on 1.1.23 and 1.1.31.

Workaround:

Changing the minimum ingressq to 4511 fixes the problem.

CSCds90673

Symptom:

After reset of ausm-8t1e1 card, the port state is active though the line is in alarm.

Conditions:

When the card is put in Bulk Mode & then a reset card is done.

Workaround:

None.

CSCdt18908

Symptom:

dspcons command 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.

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 signaling).

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:

After adding and removing the remote loopback on the AUSM line, add and remove a local loop on that line again through CiscoView

CSCdu03185

Symptom:

The policing function on VBR.2 (rt/nrt) connections on AUSM 8T1, allows more than expected CLP1 cells into the network.

Condition:

When traffic with CLP1 cells in excess of configured value is sent in ingress direction.

Workaround:

None.

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.

CSCdu34346

Symptom:

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.

Further Problem Description:

The following warning is to be expected----

addred:Prim and Sec LineModule type Mismatch. Command will proceed for the card type.

CSCdu39150

Symptom:

dspchancnt 2000 gives an error message on FRSm-2CT3

Conditions:

MGX 8230/8250 FRSM-VHS card has channel number 2000 enabled.

Workaround:

None.

CSCdu43261

Symptom:

AUSM does not display line alarm information correctly.

Conditions:

When the T1 interface is shut from the 3810

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

Symptoms:

CLI commands display the same info for ratio queue, vs weighted fair.

Conditions:

On both the dspegrq, and the cnfegrq commands.

Workarounds:

None.

CSCdu86599

Symptom:

On an 8 port CESM (AX-CESM-8T1) for the MGX8220, 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.

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

Conditions:

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

1. Go to sh in the Active PXM

2. smCardMibVer = 21 /* Change the MIB version from 23 (1.1.30) to 21 (1.1.22 and above) */

3. saveDBToArchive 7, 0 /* Create the archive file for slot 7 (VSM) with the changed MIB Version)

4. upLoadBram 7, 7 /* Write the newly created archive file to the Active and Standby disk database */

5. spmdsparchinfo 7 (on Active PXM and Standby PXM) /* Verify that the MIB version has been changed to 21 */

6. 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)

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.

CSCdv26309

Symptom:

Connection configured on FRSM 8E1 on an MGX8250 unable 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 the 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:

MGX8250 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

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 non ABR service. Code affected is when upgrading MGX8250 FRSM code from 10.0.20 to 10.0.22

Workaround:

None, unless chanservtype has already been selected other than default to ABR servicetype.

CSCdv45481

Symptom:

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.

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

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

CSCdv76770

Symptom:

PXM has a corrupted file system and the card gets reset sometimes

Conditions:

When CWM does a saveallcnf and then rename 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.

CSCdw10025

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

CSCdw11628

Symptom:

Async updates do not work

Conditions:

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.


Known Anomalies for Platform Software Release 1.1.42 and Service Module Firmware

The following is the list of known anomalies in the service module firmware and the Release 1.1.42 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.

Bug ID
Description

CSCdm92345

Symptom:

The VHS SM have either DAX or FEEDER connections on the logical port which is simulated with some kind of signaling. Now if configure the line in logical (diagnostic) loopback, the CWM shows connections Failed but after deleting the diagnostic loopback from line connections do not come back in OK state even though traffic runs well through the connections. CLI shows the correct status of the connections but CWM does not show the correct status of the connections once connections go to the Fail state.

Condition:

As above.

Workaround:

None.

CSCdp00537

Symptom:

Shelf Integrated Alarm not updated correctly and traps are not send consistently when fan tray is removed.

Conditions:

When a fan tray is removed.

Workaround:

None

CSCdp44837

Symptom:

When deleting large no. of connections using a script, it was found that for some connections, the resources were not freed properly.

Conditions:

This problem was encountered sometimes when deleting more than 500 connections using a single "delchans" command.

Workaround:

Do switchcc. It is recommended not group such a large number of connections in each "delchans" command. Restricting to 50 or 100 connections per delchans would help workaround this problem.

CSCdr71479

Symptom:

When using 1:N redundancy on MGX8250/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 seen in 1.1.21, 1.1.23, 1.1.31, and 1.1.32. 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.

CSCds10377

Symptom:

When one of the OC-12/OC-3 lines are in alarm the CLI dspapsln shows the line status as "ALM" instead of specifically indicating LOS/LOF.

Conditions:

When a OC-12/OC-3 line/trunk configured for APS goes into alarm because of LOS or LOF.

Workaround:

Use the dspalm CLI command to obtain the correct alarm status.

CSCds10382

Symptom:

A descriptive line status is not displayed in the dumpaps command.

Conditions:

When APS is configured for OC-12/OC-3 line/trunk and the line status is checked using dumpaps command.

Workaround:

Use the dspalms CLI command for descriptive status of the lines.

CSCds10566

Symptom:

The APS configured goes into "Architecture Mismatch".

Conditions:

An OC-12/OC-3 line/feeder trunk is configured as Unidirectional mode on the BXM and Bi-directional mode on the PXM. The mode mismatch was detected by PXM, but incorrectly blocked all APS switching function. According to GR-253 the APS switching should function normally as unidirectional on both sides.

Workaround:

None.

Further Problem Description:

This feature is not supported in MGX 8800 Release 1.

CSCds11679

Symptom:

BPX receives lots of traps 50609 and 50612 from the MGX feeder.

Conditions:

When the backcard is not inserted properly, and causes the APS line to continuously change state.

Workarounds:

1. Remove and insert the backcard properly.

2. Delete the configured APS configuration.

CSCds14512

Symptom:

The OC-12 feeder trunk was configured as 1+1 unidirectional non- revertive mode on the PXM and the Agilent test set was sending invalid "SF-H" K2 bytes to the PXM. The "dspapsln" command did not display "protocol switch byte failure" after detecting the invalid K2 bytes.

Conditions:

When APS is configured and the remote end sends invalid "SF-H" K2 bytes.

Workaround:

None.

Further Problem Description:

The invalid K2 bytes is not being detected by the firmware.

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 confirms incorrect configuration modifications. This was noticed when the timeslot value was modified.

Conditions:

When you try to modify the timeslot value for an unstructured port.

Workaround:

Under investigation.

CSCds60139

Symptom:

Minor alarm on the Active PXM for about 4 - 5secs

Conditions:

1. Have a Y cable on the OC3 trunk

2. Reset the standby PXM

Workaround:

None

Further Problem Description:

On resetting a standby PXM card, the active PXM picks up errors on the trunk. The errors were Code Violations.

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

CSCds86780

Symptom:

dspcd, dspln, dsplns, dspport, dspports, dspcon, and dspcons never return the prompt after adding multiple 3 seg connections using script.

Conditions:

add multiple 3 seg cons om MGX8850 using script

Workaround:

None

CSCds88422

Symptom:

Cell loss occurs twice after switchcc on PXM, while CESM was used as primary.

Conditions:

Cell loss occurred twice after switchcc on PXM, while CESM was used as primary. -1st cell loss occurred when ran switchcc on PXM. -2nd cell loss occurred when the status of PXM, which was reset by "switchcc", became standby.

Workaround:

None

CSCds90439

Symptom:

When doing a dsplog on the active PXM you get hung up. Have to do control c to get back. You should be able to end the Semaphore session to clear this but the reason for this bug is to identify any other commands this might affect.

Conditions:

Running 1.1.23 on the PXM1-4-155

Workaround:

To identify the problem, from the active PXM, use "ll" to verify that a LOG exists and "users" to identify any sessions used for a long period of time.

CSCdt08834

Symptom:

dspconcnt on feeder trunk on PXM doesn't work -- command works only on UNI port

Workaround:

None

CSCdt19805

Symptom:

Executed switchyred on these FRSM's and PVC's that were in alarm showed clear in the dspcds.

Conditions:

Performing Softswitch

Workaround:

No known workaround.

CSCdt21978

Symptom:

Popup message is appearing when executing commands.

Conditions:

After a resetsys is done and then a dspprfhist.

Workaround:

None

CSCdt22274

Symptom:

Sonet port is receiving errors

Conditions:

Port is in local loopback and after the almcnt is cleared, the port errors continue to increment.

Workaround:

None

CSCdt27067

Symptom

tstconseg fails intermittently when executed from the PXM.

Conditions

Normal conditions.

Workaround

None.

CSCdt33218

Symptom:

CWM is receiving too many traps from the MGX.

Conditions:

When a APS Line Failure occurs and a message is logged on the MGX.

Workaround:

None

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

CSCdt50211

Symptom:

PSU Failure is not indicated either in dsplog or in dspshelfalm.

Conditions:

When there is a PSU failure.

Workaround:

None.

CSCdt63269

Symptom:

The SES trunk can not recover from feeder trunk failure even though the IGX shows trunk "Clear - OK".

Conditions:

SES feeder trunk failed and recovered.

Workaround:

Replug the cable.

CSCdt74149

Symptom:

Select Card and then Configure from CiscoView. For FRSM-8T1/E1 or AUSM 8T1/E1 missing parameters from GUI: Line Module Description Line Module Serial Number Card Integrated Alarm BitMap This information is present on a FRSM 2CT3 card.

Conditions:

Normal conditions.

Workaround:

Use CLI

CSCdt80701

Symptom:

primary rpm goes to mismatch state on a softswitch command

Conditions:

add rpm to redundancy 1:N following a clrsmcnf when rpm had 700+ connections and sub-interfaces

Workaround:

issue a second resetcd to rpm following the clrsmcnf

CSCdt90915

Symptom:

I tried to put a remote loopback using the addlnloop command on a PXM card. Although I specified a remote line loop, it was putting the line in local line loop instead.

Conditions:

remote loop using addlnloop

Workaround:

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

CSCdu12986

Symptom:

Cannot run dsplog cli command on the node. (on the active card) Can run other command like version, and dspcds. Impacts the execution of proactive scripts running on the node to collect logs on a daily basis.

Conditions:

unknown

Workaround:

None

CSCdu17346

Symptom:

CLI clock source commands does not return accurate information about the external clock.

Condition:

With the external clock configured for E1, 75 ohms impedance and a 1.544 MHz T1 clock coming in, all commands to examine clock status say the external clock is OK and being used. This even though the "E1" clock is running at 1.544 MHz, not 2.048 MHz. T1 clock is supplied from Fireberd4000 T1/FT1 interface, slaved to a HP33120A frequency synthesizer at 1.544000.0 MHz. Looked at the 8K clock and the external clock and they were not synched. This indicates the board rejected the wrong frequency clock and switched back to its internal clock, to generate the 8K clock. Yet all info we can see says the external E1 clock is being used.

Workaround:

None

CSCdu19822

Symptom:

Frames gets CLP tagged when DE is disabled at the ingress and ingress is pumped at more than cir

Conditions:

DE is disabled at the ingress and ingress is pumped at more than cir

Workaround:

None

CSCdu22992

Symptom:

No messages in CWM event log when standby PXM had failed due to H/W issue.

Conditions:

Unknown

Workaround:

Unknown

CSCdu26221

Symptom:

MIB files are not compilable with some specific compilers.

Conditions:

When trying to compile MIB files.

Workaround:

None.

CSCdu28611

Symptom:

If you have a NNI connection built from a FRSM 2T3 via the PXM feeder trunk to an IGX, the IGX won't see ABIT alarm even if the FRSM is receiving ABIT alarm on the NNI link to another network.

Conditions:

Unknown

Workaround:

None.

CSCdu29306

Symptom:

Card stops passing data. Dsportcnt will show LMI signaling timeouts, data incrementing only in the Tx direction. Port will register LMI failure.

Conditions:

Unknown.

Workaround:

Card reset.

CSCdu38671

Symptom:

Clock controller running on internal oscillator after upgrade.

Conditions:

After upgrade from 1.1.23 to 1.1.34

Workaround:

Reconfigure the clock. For the current scenario, from "dspcurclk" we find that the Trunk Interface 7.1 is set as Primary, to set the same the command is "cnfclksrc 7.1 p".

CSCdu38711

Symptom:

All PSU is showing 'missing'

Condition:

Not known.

Workaround:

None

CSCdu41961

Symptom:

data transfer stopped for approx 1min, 25 secs.

Conditions:

Upon SRM active backcard removal.

Workaround:

None

CSCdu45324

Symptom:

Traffic test using tester inputting 60cps across 500 SIW connections built from BPX network running 9.2.37 and passing through two ATM nni gateways and terminating on a PXM1 feeder and FRSM card shows dicards on FRSM due to CRC and assembly errors.

This mainly occurs on the last 5 ports of the FRSM.

Conditions:

FRSM heavily loaded PXM1 running 1.1.32 Test environment

Workaround:

None.

CSCdu46419

Symptom:

With UBR connection, observed GCRA2 non-conforming cells on the ingress channel.

Conditions:

UBR is configured on the PXM to RPM and no policing is enabled. Even with OC3 rate, there are GCRA2 non-conforming cells on the ingress.

Workaround:

None

CSCdu48231

Symptom:

Ilmi failure on ports.

Condition: When ilmi keep alive option is turned ON for the port and traffic flowing through the card.

Workaround:

None

CSCdu49191

Symptom:

The command "cnfimatst" does not correctly report back the status if the link if the pattern 255 is used. It will always report "failed" even when the link is fully operational.

Conditions:

This will happen under all conditions. It is know to exist is version 10.0.21

Workaround:

The test appears to work with data values other that 255. The command cnfimatst can be used to change the data value of the test:

m8250-5a.1.1.AUSMB8.a > cnfimatst 
ERR : incorrect number of parameters (not enough) Syntax : cnfimatst 
"group_num Test_link_num test_pattern test_proc_status" IMA group number 
-- value ranging from 1 to 8 test link -- test link : Value in the range 1 
to 8 for specific link and value -1 for implementor to choose the testlink 
test pattern -- test pattern : Value in the range -1 to 255 test 
procstatus -- test procstatus : Value in the range 1 to 2. For cnfimatst 
it is 2 and for clrimatst it is 1 
possible errors are : a) illegal/invalid/bad parameters b) IMA group 
doesn't exists c) One of the lines is not yet enabled d) Internal 
connectivity is going on on this group e) TetsProcStatus should be 2 
m8250-5a.1.1.AUSMB8.a > cnfimatst 1 1 222 2 

Further Problem Description:

When this command is enabled, it will use the IMA ICP cells to enable the test, and transmit a pattern (only one byte of the ICP cell) across a specified link of the ima group. The far side will see the test enabled and transmit that same pattern back across ALL the links of the IMA group.

If the pattern is returned, the test will pass. If it does not, the test will fail.

This is an example of a failed output:

m8250-5a.1.1.AUSMB8.a > dspimatst 1 
Group No            : 1 Test Link           : 1 Test Status         : Link 
Fail Test Pattern        : 255 
--------------------------------------------------- 

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.

CSCdu52789

Symptom:

Port alarm present on the AUSM card.

Conditions:

Even after an upgrade, and there are no port alarms, or line alarms.

Workaround:

Wait a while and the alarm finally clears itself.

CSCdu52855

Symptom:

chkslotcon is not representing the correct connection information.

Conditions:

This occurred right after a switchcc on the shelf.

Workaround:

None

CSCdu54413

Symptom:

LAN IP change is not reflected on NW Browser

Condition:

When the LAN IP is changed

Workaround:

None.

CSCdu59142

Symptom:

APS Line does not switch to PROT line after removing the back card on which working line resides. Also the working line is shows as OK.

Conditions:

Remove the PXM back card on which working (active) line resides.

Workaround:

Before the back card is removed, following things need to be done.

1. PXM directly associated (same slot as the back card) with the back card which is to be removed, should be in STANDBY state. i.e. if back card of slot 7 is to be removed, then PXM in slot 7 should be in STANDBY state. This can be achieved with a switchcc.

2. All the APS line should be switched to the back card which is directly associate with the ACTIVE PXM. (i.e. back card in the same slot as the front card of Active PXM). This can be done using a command switchapsln

CSCdu61217

Symptom:

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

Conditions:

unknown

Workaround:

None

CSCdu63700

Symptom:

MGX1 connected to MGX2 with OC12 1+1APS. When the WLine failed, MGX2 switched to PLine; but MGX1 stayed at WLine although it detected WLine in Alarm.

Conditions:

Connected MGX1 to MGX2 as feeder via OC12 1+1APS, WLine as active line. Removed the WLine Backcard from MGX2 side, WLine in SF, PLine in OK; MGX1 WLine in ALM, PLine in P_D states, with TxK1=C0, RxK1=C1.

Workaround:

Manual Switchaps to PLine before removing the WLine Backcard.

CSCdu66767

Symptom:

pxmCurClkSourceTrap is not generated properly.

Conditions:

When there is a clock switch.

Workaround:

None.

CSCdu72687

Symptom:

Can't change donothold from front card from CiscoView.

Conditions:

Always

Workaround:

Use CLI

CSCdu73201

Symptom:

Active line switches to working.

Conditions:

This happens if we switchcc with Protection line as active.

Workaround:

None.

CSCdu76037

Symptom:

Frames were dropped when traffic was pumped at full T3 on both the ports of the FRSM-2T3 card.

Conditions:

When traffic was being pumped at 70% of T3 rate on both the ports there were frame drops.

Workaround:

No workaround.

CSCdu77273

Symptom:

Frames are being dropped when traffic is pumped at full T1 rate. But when the traffic rate is 98% of T1 rate there were no drops.

Conditions:

Not known

Workaround:

None

CSCdu77558

Symptom:

On a fully loaded shelf (with 12 RPMs), if multiple redundant groups, if multiple resetcds followed by switchcc causes shelf to reset.

Condition: On a fully loaded shelf (with 12 RPMs), if multiple redundant groups, if multiple resetcds followed by switchcc causes shelf to reset.

Workaround:

Wait for at least 5-10 mins before doing the switchcc.

CSCdu82493

Symptom:

On a CBR connection SCR and MBS shows numeric values. This should be N/A

Conditions:

N/A

Workaround:

None

Further Problem Description:

This is a display issue, these parameters are not used for a CBR connection. These fields are used for other types of connections and the minimum values allowed for these fields is more than 0 as per the mib.

CSCdu84496

Symptom:

Line enabled on PXM 1 is not reflected on CWM (network browser)

Condition: Line enabled on PXM1

Workaround:

None

CSCdu86525

Symptom:

PXM1 resets due to watchdog timeout reset.

Conditions:

Unknown.

Workaround:

None. This problem is a pure software issue and there is no need to replace hardware. PXM will reset due to watchdog timeout and come up to active/standby state.

Further Problem Description:

Software exceptions due to unknown reason. From the current exception logs in the core, it is not sufficient to decide the root cause of the first exception. However, the events after the first exception showed some flaws in design.

CSCdv11015

Symptom:

No Sonet option under the xcnfalm command

Conditions:

Normal operation.

Workaround:

N/A

CSCdv14622

Symptom:

PXM reject addcon

Condition:

Unknown

Workaround:

Unknown

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

CSCdv19158

Symptom:

PXM Bootcode burn failed on the standby card.

MGX nodes were failing pxm bootcode burns, in every instance the log has a message to the effect that "DB table is full all 20 entries used.

Workaround:

Patch Memory and the bootcode upgrade went fine.

Further Problem Description:

During the upgrade if bootcode upgrade don't go.Log needs to be checked for error messages of database table full and software errors.

CSCdv28342

Symptom:

When you add an incomplete conn. from FRSM to PXM with vci = 0, it's

shown as ok

Condition:

vci = 0

Workaround:

Use non-zero vci.

CSCdv29288

Symptom:

ModConn Test failing

Conditions:

Cannot do modconn via GUI for updating MIR,QIR at the same time

Workaround:

Change MIR, QIR one at a time instead of at the same time via GUI

CSCdv37361

Symptom:

addcon/dspchans/dspchan(channel#) need to be more specific for vbr-nrt.

Conditions:

See below

Workaround:

None

Further Problem Description:

MGX-7.1.7.PXM.a > addcon ERR: incorrect number of parameters: (not enough) 
Syntax: addcon "port_no conn_type local_VPI local_VCI service [CAC] 
[mastership] [remoteConnId]" port_no -- a number 1..32 conn_type  -- a 
number 1..2 (1: vpc 2: vcc) local_VPI -- a number 0..4095 local_VCI -- a 
number 0..65535 service -- a number 1..5 (1:cbr 2:vbr 3:abr 4:ubr 
5:vbr-rt) CAC -- connection admission control, a number 1..2 (1:enable 
2:disable default:2) mastership -- a number 1..2 (1:master 2:slave 
default:2) remoteConnId -- a string (format: 
NodeName.SlotNo.PortNo.VPI.VCI), required if mastership is 1 (master) 
MGX-7.1.7.PXM.a > dspchans 
Chan Stat Intf locVpi locVci conTyp srvTyp PCR[0+1] Mst rmtVpi rmtVci 
State 
------------------------------------------------------------------------ 
---- 17 ADD    4    131      67  VCC   CBR          50 Mst   131      65 
alarm 18 ADD    3    131      65  VCC   CBR          50 Slv   N/A     N/A 
alarm 20 ADD    3     10     100  VCC   CBR          50 Slv   N/A     N/A 
alarm 21 MOD    4    132      11  VCC   CBR         100 Mst   132      11 
alarm 22 MOD    3    132      11  VCC   CBR         100 Slv   N/A     N/A 
alarm 23 ADD    1     10     105  VCC   CBR          50 Mst    10     106 
alarm 24 ADD    4     10     101  VCC   CBR          50 Mst    10     100 
alarm 26 MOD    1     10     102  VCC   CBR         100 Slv   N/A     N/A 
alarm 27 ADD    2     10     106  VCC   CBR          50 Slv   N/A     N/A 
alarm 28 MOD    2     10     103  VCC   CBR         100 Mst    10     102 
alarm 29 ADD    2    140     999  VCC   CBR          50 Mst   140     999 
alarm 30 ADD    1    140     999  VCC   CBR          50 Slv   N/A     N/A 
alarm 33 MOD    2      0     100  VCC   VBR      115131 Mst     0     100 
alarm 35 ADD    2    140     888  VCC   CBR          50 Slv   N/A     N/A 
alarm 37 MOD    2      0     101  VCC   VBR        4000 Mst     0     101 
alarm 38 ADD    4    132     811  VCC   CBR          50 Mst   132     811 
alarm 39 ADD    3    132     811  VCC   CBR          50 Slv   N/A     N/A 
alarm 40 ADD    1    140     888  VCC   CBR          50 Mst   140     888 
alarm 65 ADD    1     91       4  VCC   CBR          50 Mst    91       4 
normal 

CSCdv37361
(continued)

Type <CR> to continue, Q<CR> to stop: 
Chan Stat Intf locVpi locVci conTyp srvTyp PCR[0+1] Mst rmtVpi rmtVci 
State 
------------------------------------------------------------------------ 
---- 66 ADD    4     91       4  VCC   CBR          50 Slv   N/A     N/A 
normal 75 MOD    1     61      50  VCC   CBR        2561 Mst     0       0 
alarm 79 MOD    1     61      40  VCC   CBR        5291 Mst     0       0 
normal 81 MOD    1     61      41  VCC   CBR        4097 Mst     0       0 
normal 
MGX-7.1.7.PXM.a > dspchan 33 bbChanCnfNum                : 33 
bbChanRowStatus             : MOD bbChanConnType              : VCC 
bbChanServiceType           : VBR bbChanConnDesc              : 
0x0000000000000000000000000000000000000000 bbChanSvcFlag               : 
PVC bbChanIfNum                 : 2 bbChanVpi                   : 0 
bbChanVci                   : 100 bbChanUpcEnable             : ENA 
bbChanUpcPCR                : 115131 bbChanUpcCDVT               : 250000 
bbChanUpcSCR                : 115131 bbChanUpcMBS                : 1000 
bbChanUpcMCR                : 7 bbChanGcra1Action           : Discard All 
NonConform Cells bbChanGcra2Action           : Tag Cells 
bbChanUpcSCRPolicing        : CLP0 bbChanEfciThreshold         : 98304 
bbChanDiscardOption         : CLP Hysteresis bbChanFrmDiscardThreshold   : 
0 bbChanClpHiThreshold        : 0 
Type <CR> to continue, Q<CR> to stop: bbChanClpLoThreshold        : 0 
bbChanCongstUpdateCode      : Dont Update bbChanMaxCellMemThreshold   : 
131072 bbChanIngrPercentUtil       : 100 bbChanEgrPercentUtil        : 100 
bbChanEgrSrvRate            : 115131 bbChanOvrSubOvrRide         : Enable 
bbChanLocalVpi              : 0 bbChanLocalVci              : 100 
bbChanLocalNsapAddr         : 0x4D47582D37000000000000000000000000000200 
bbChanRemoteVpi             : 0 bbChanRemoteVci             : 100 
bbChanRemoteNsapAddr        : 0x4D47582D3700000000000000000000001B000100 
bbChanMaster                : Mst bbChanRtePriority           : 1 
bbChanMaxCost               : 255 bbChanRestrictTrkType       : No 
Restriction bbChanTestType              : 3 bbChanTestState             : 
Not In Progress bbChanTestResult            : 0 bbChanTestTypeCPESide       
: 2 bbChanTestStateCPESide      : Not In Progress 
Type <CR> to continue, Q<CR> to stop: bbConnVpcFlag               : VCC 
bbConnServiceType           : VBR bbConnPCR                   : 115131 
bbConnSCR                   : 115131 bbConnPercentUtil           : 100 
bbRemoteConnPCR             : 115131 bbRemoteConnSCR             : 115131 
bbRemoteConnPercentUtil     : 100 
_______________________________________________ 

CSCdv43341

Symptom:

When pulling out standby PXM1 card, yellow alarm disappears after a while on the active card.

Conditions:

Firmware: 1.1.32 Commands:dspcds (slot 7 active,slot 8 empty PXM1-OC3) PXM1-FunctionModuleHWRev: A0 LineModuleType: PXM-UI

Workaround:

None- Hopefully DE can provide a workaround prior to fix.

CSCdv44392

Symptom:

If a currently active primary clock source is removed, the system switches to the internal clock source. If the primary clock source is re-attached, the system switches to the primary clock source and all works correctly as designed. The current clock source is correctly reflected when using the (CmdBold)"dspcurclk"(noCmdBold) command. However, the nodal logs show indifferent messages as shown in the description This is isolated to a primary clock source where the primary clock source is an APS trunk.

Conditions:

FunctionModuleFWRev: 1.1.34

Workaround:

Always check the dspcurclk<noCmdBold" command output for the correct information on currently active clock sources.

CSCdv49121

Symptom:

Whenever a ping is performed from the rpm to the pxm (physically looped back), the pxm counters show some large(1285 packets) number when we're only expecting 5 packets.

Conditions:

Air Condition customer certification lab.

Workaround:

None

Further Problem Description:

Whenever a ping is performed from the rpm to the pxm(physically looped back), the pxm counters show some large(1285 packets) number when we're only expecting 5 packets.

Here's what Cisco has investigated so far: We have a connection built between the RPM and PXM-OC3 port and we have a physical loopback connected on the pxm-oc3 port. When I tried to ping the ip address, the packet counter on switch interface show 1285 packets instead of 5 packets. If I have a real CPE device connected to the oc3 port, the counter shows to be ok.

Please see the following -

MGX-11.1.8.PXM.a > dspchancnt 40 Channel Number               :         40 
Channel State                :     normal Channel Ingress State        :     
normal Channel Egress State         :     normal CLP=0  Rcvd. Cells           
:       3845 CLP=1  Rcvd. Cells           :          0 GCRA1  Non 
Conforming Cells  :          0 GCRA2  Non Conforming Cells  :          0 
EOF    Cells Rcvd.,  to CBus :       1285 CLP=0  Discard Cells to CBus :          
0 CLP=1  Discard Cells to CBus :          0 CLP=0+1 Xmtd. Cells  to CBus :       
3845 CLP=0  Xmtd. Cells   to Port :       3845 CLP=1  Xmtd. Cells   to 
Port :          0 CLP=0  Discard Cells to Port :          0 CLP=1  Discard 
Cells to Port :          0 
-------------------------------------------------------------------- 

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.

CSCdv50123

Symptom:

The addchanloop doesn't seem to work properly on FRSM cards. Tests were carried out on the FRSM8E1 & FRSM2T3.

If you addchanloop first & then generate traffic on a foresight connection you get discards. If you generate traffic first & then addchanloop you get no discards.

If you generate traffic to a physical loop on the port you get no discards.

Conditions:

As above. Put the loop on first & then start the traffic generator.

Workaround:

If you make QIR=PIR you don't get the problem.

CSCdv53678

Symptom:

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

Conditions:

Customer was running a test in which a specific sequence of actions were taken:

Initial conditions: MGX 7.1 and BPX 1.1 fibers active, all fibers ok,

no last user APS request shown, MGX card 7 active 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

n040_mgx.1.7.PXM.a > dspapsln SlotLine Type  Act W_LINE P_LINE APS_ST 
CDType Dirc Revt LastUsrSwReq 
------------------------------------------------------------------------ 
7.1&8.1  1+1_2 7.1 OK     OK     OK     OC-3   UNI  NRV  FORCE_SWITCH 

j. after that, when going back to the initial conditions using "switchapsln 1 c" this caused the MGX to switch the active fiber from 7.1 to 8.1:

n040_mgx.1.7.PXM.a > switchapsln 1 c 
n040_mgx.1.7.PXM.a > dspapsln SlotLine Type  Act W_LINE P_LINE APS_ST 
CDType Dirc Revt LastUsrSwReq 
------------------------------------------------------------------------ 
7.1&8.1  1+1_2 8.1 OK     OK     OK     OC-3   UNI  NRV  NO_REQUEST 

After this, manual switching back to 7.1 would no longer work. The commands dspalm -sonet 7.1, dspalmcnt -sonet 7.1, and dspatmlncnt 1 showed no errors on line 7.1.

n040_mgx.1.7.PXM.a > switchapsln 1 m Manual Switching is blocked by SF or 
SD on PROT line 
n040_mgx.1.7.PXM.a > switchapsln 1 f 
n040_mgx.1.7.PXM.a > dspapsln SlotLine Type  Act W_LINE P_LINE APS_ST 
CDType Dirc Revt LastUsrSwReq 
------------------------------------------------------------------------ 
7.1&8.1  1+1_2 7.1 OK     OK     OK     OC-3   UNI  NRV  FORCE_SWITCH 
n040_mgx.1.7.PXM.a > switchapsln 1 c 
n040_mgx.1.7.PXM.a > dspapsln SlotLine Type  Act W_LINE P_LINE APS_ST 
CDType Dirc Revt LastUsrSwReq 
------------------------------------------------------------------------ 
7.1&8.1  1+1_2 8.1 OK     OK     OK     OC-3   UNI  NRV  NO_REQUEST 

Workaround:

None

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 known

CSCdv55459

Symptom:

FRSM card loses configuration after power black out.

Conditions:

Total power failure on the MGX node. PXM was running 1.1.31

Workaround:

'clrsmcnf' and reload configuration.

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" would cause the CLI to hang.

Conditions:

Conditions with the customer's node and network were deemed as normal. System idle was at 95%.

Workaround:

Switchcc was found to be one workaround for this problem.

CSCdv62107

Symptom:

Unknown line number sent by switch for PXM-OC12

Conditions:

When PXM-OC12 is used

Workaround:

None

CSCdv62206

Symptom:

stdby pxm reset due to software error

Conditions:

Node in alarms state, while script is running to monitor the node, and possible provisioning during this event.

Workaround:

WDT cleared the softerror, upon completion of reset from shell.

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

CSCdv79470

Symptom:

The line goes in and out of "clock rate out of bounds alarms". This causes a flood of line traps and PXM starts reporting software errors 20182 and 21501. Refer to bug description for specific PXM errors.

Conditions:

When a loopback plug is plugged on a dte interface.

Workaround:

Configure the interface to DCE.

CSCdv79871

Symptom:

Unable to cc into RPM-PR

Condition:

While trying to cc to an RPM_PR card (with no RPM redundancy configured), received following error: mgx1.1.7.PXM.a > cc 10 Err: cliCroiPsrWrite(): ipc_open_port_by_name(RPM Slot 10:Console): failed

Workaround:

None

CSCdv84678

Symptom:

RPM card got stuck in boot state.

Conditions:

After RPM card was reset. The card stuck in boot state because of bad IOS image on the PXM disk.

Workaround:

Download the IOS image again.

CSCdv84768

Symptom:

SCM queue overflow was seen and the AUSM cards were stuck in reserved state

Conditions:

Happened spontaneously on a working shelf

Workaround:

Perform a switchcc

CSCdv84864

Symptom:

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

Conditions:

Unknown.

Workaround:

Need to manually correct the situation.

CSCdv84978

Symptom:

Clock source change triggers a PAR error 21134

Conditions:

Clock source changes.

Workaround:

None.

CSCdv85890

Symptom:

addcon/dspchans/dspchan (number) does not display connection service as vbr-nrt.

Conditions:

Whenever addcon/dspchans/dspchan is executed.

Workaround:

None.

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.

CSCdv88025

Symptom:

Improper access level control for some command

Conditions:

login through console port.

Workaround:

none

CSCdv88082

Symptom:

Unable to pump traffic at full port speed. Causes discards.

Conditions:

Traffic at full port speed.

Workaround:

None at present.

CSCdv89742

Symptom:

clralmcnt <CmdArg>-ds3<noCmdArg> does not clear the counters for the SRM.

Conditions:

Workaround:

Use clralms <CmdArg>-ds3<noCmdArg>.

CSCdv89819

Symptom:

Once the popeye node went logical unreachable to the bpx. Had to execute a switch cc to recover the node. The cause seems to be due to lmi task failure.

Conditions:

Normal

Workaround:

Switchcc

CSCdv90088

Symptom:

POPEYE with PXM1 went logically/LMI unreachable. Connections were failed, All SMS and standby pxm showed failed to active PXM. Could Console into standby PXM and it showed "standby"

Conditions:

Normal

Workaround:

Reset of active PXM caused switchover to the standby pxm. Node returned to normal after that.

CSCdv90213

Symptom:

Watch dog timeout on active PXM switched over to standby and core was dumped.

Conditions:

Normal operation

Workaround:

None

CSCdw00670

Symptom:

Interface and connection provisioning failed due to IPC timeouts. But CC to RPM, IPC polling and heartbeat works fine. RPM card looks healthy in terms of CPU and memory.

Conditions:

The events, commands which lead to this situation are unknown at this point of time.

Workaround:

Controller card switchCC cleared this issue.

Further Problem Description:

1. DE tried the following efforts to reproduce this issue/to find out RCA.

a. Used scripts to provision the interfaces and connections. There was no delay given in between the connection additions. Added 600 interfaces and 600 connections.

Results: i) All the provisioning went thru fine. ii) Didn't observe any delays.

b. reviewed the code thoroughly on both PXM and RPM side. Didn't find any issues related to this problem.

Also, some of the captures are missing to pinpoint the exact root cause.

With the captures available and the reviews, we suspect that the IPC messages could have been dropped or processed very slowly on the PXM side which might have lead to this issue. Verified this with a debug image and observed the same symptoms.

In case, if this problem happens, try to call DE immediately, otherwise please capture the following and add it to this DDTS.

On RPM side: Enable the terminal monitor: Execute "term mon" in config mode.

1. sh version

2. sh log

3. sh proc cpu

4. sh memory

5. sh tech

6. sh ipc queue

7. sh ipc ports

8. sh ipc status

9. debug ipc packets

10. dir c:

CSCdw00670
(continued)

On PXM side:-

1. dspcds

2. version

3. dspparifs

4. dspcons

5. dsplog

6. core hot-dump

7. dbmShow (from shellConn)

8. i (from shellConn)

9. scmCardShow <slot #> (from shellConn)

10. ssiSemList 1 (from shellConn)

11. sarShow (from shellConn)

12. dbgOn "RVT",5,1 (when doing provisioning) (from shellcon)

13. dbgOn "IPC",5,1 (when doing provisioning) (from shellcon)

14. rmm_print_stat (from shellcon)

15. ipc_print_stat (from shellcon)

CSCdw01418

Symptom:

Unable to do a noderesync from MGX8850 to CWM 10.4.x. Problem with FRSM-HS1B

Conditions:

With a FRSM-HS1/B present in the node.

Workaround:

None.

CSCdw01992

Symptom:

PXM spontaneously switched over.

The following error messages scrolled across the screen

################################### ###### SYSTEM ERROR 20182 -426933 
2025115134 50338856 -2029099400 ################################### 
#################################### ###### SYSTEM ERROR 21501 1024 
805371649 -2141828462 -2143987176 ################################### 
vsim fatal: can't get message buffer 

Conditions:

DS3 on FRSM 2CT3 was flapping causing multiple alarms. This caused a buffer depletion.

Workaround:

Trap squelching can be used or looping the DS3 will quiet the alarms.

CSCdw02489

Symptom:

Could not cc to the standby card, and the scm retry counts was incrementing Active PXM declared loss of core redundancy.

Conditions:

Node populated with VISM and AUSM Cards.

Workaround:

Confirm the standby has updated database and execute a swithcc

CSCdw02677

Symptom:

FRSM-2CT3 keeps resetting.

Condition:

Certain enable.stats file generated by CWM 10.4.10 patch 1J

Workaround:

Disable the new stats ID 25, 27,28

CSCdw03604

Symptom:

Inconsistency in databases on CESM-T3/E3

Conditions:

CESM-T3/E3

Workaround:

Under Investigation

CSCdw03737

Symptom:

The connection from FRSM-2CT3 to FRSM-8T1 through BPX cloud, does not pass traffic. tstcon on the connection fails though the connection is state reported is OK. dspsarcnt shows Rx=0.

Conditions:

CPE--------FRSM(2CT3)--------PXM---------BPX-------cloud-----BPX------PXM-
----FRSM(8T1)---CPE 

Workaround:

Delete and add back the connection.

CSCdw04842

Symptom:

Controller status missing after abort from newrev state

Conditions:

1. Started with PXM version 1.1.25

2. Performed install bt 1.2.00As.

3. Performed install 1.2.00As (controller status ok).

4. Performed newrev 1.2.00As (controller status ok).

5. Performed workaround for fallback and executed abort

Workaround:

None: Under Investigation

Further Problem Description:

Have not seen the problem when I tried to recreate it in the lab. Problem under investigation.

CSCdw05153

Symptom:

Statistics on MGX goes to BadFileList since they are invalid files.

Conditions:

Collect PXM stats on MGX node which is connected to MGX 2.0 node. Probability of the hitting the problem increases if there are more number of connections.

Workaround:

None

CSCdw06204

Symptom:

Available DRAM dropped below 28k

Conditions:

Normal.

Workaround:

Core dump and Switchcc

CSCdw07044

Symptom:

When configuring CISCO lmi on a mgx 8250 @ 1.1.34 the frsm allows connections to be built using dlci ranges that are reserved without a cli or node log warning. When port is configured for lmi (annexd/or annex a) reserved dlic cannot be configured as expected.

Conditions:

When a connection is added with a reserved DLCI value and a port which has signaling configured.

Workaround:

Do not add the connections with reserved DLCI.

CSCdw08896

Symptom:

Node went unreachable, could not executed dsptrks, dcondb 4 3. Could execute dspchans, and dsptotals

Conditions:

At the point in time when unreachable occurred, 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.

CSCdw09234

Symptom:

The lines of Service Module go into alarm

Conditions:

Lines should be in bulk mode and the front card of Active SRM should be pulled out

Workaround:

If you need to pull out the Active SRM front card, perform a switchcc first

CSCdw09468

Symptom:

When dsperr with page mode off after an interval the PXM switches over

Conditions:

Active PXM, dsperr , pagemode off.

Workaround:

Before issung dsperr, make sure that pagemode is ON by issuing 'pagemode'. If it's OFF, use `pagemode ON' command.

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.

CSCdw10343

Symptom:

There is no cli to display and clear the slip counters

Conditions:

There is no cli

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 'runslftstno 8' is entered.

Conditions:

Normal

Workaround:

None

CSCdw18515

Symptom:

Whilst doing "write memory" on an RPM-PR card seeing a warning message "Configuration file buffer full"

Conditions:

RPM:12.2.4(T1) RPM Configuration cannot fit into NVRAM while doing "write memory" Uncompressed RPM configuration exceeds 128KB "service compress-config" is not enabled.

Workaround:

Enable "service compress-config"

CSCdw20217

Symptom:

The FRSM-HS1/B module for the MGX8220/8230/8250 fails. In dspcds the FRSM shows as Failed.

Conditions:

This has been observed in PXM version 1.1.34, FRSM firmware 10.0.22.

Workaround:

No known workaround. Resetting the card via resetcd <CmdArg>slot<noCmdArg>.

CSCdw24512

Symptom:

PXM continuous reboots, with tRootask failure.

Conditions:

DB corruption

Workaround:

Rename/delete the DB directory

CSCdw24938

Symptom:

PXM switchover due to software error reset

Conditions:

Happened spontaneously

Workaround:

None as the new PXM should take over if there is core card redundancy

Further Problem Description:

None. We need to review the core dump to find out what caused the software error reset.

CSCdw26129

Symptom:

When the redundant card fails, no trap gets generated.

Conditions:

Workaround:

None

CSCdw28353

Symptom:

Database inconsistencies between the CWM and the switch for channel states.

Conditions:

Happens whenever there is a change in connection states

Workaround:

None.

Further Problem Description:

This is a new feature that needs to be implemented on all SMs.

CSCdw28812

Symptom:

No "card removed" trap from node when PXM is removed.

Conditions:

When the active PXM is pulled out

Workaround:

None.

CSCdw30961

Symptom:

Both Primary and secondary redundant pair become active.

Conditions:

Reset active card twice and do a switchcc

Workaround:

Do switchcc only when primary or secondary is in active state.


Compatibility Notes

MGX 8230, MGX 8250, and MGX 8850 Software Interoperability with Other Products

Platform Software:

PXM 1.1.42

Compatible BPX Software:

Switch Software 9.2.30 release or higher for BPX and BXM firmware (Refer to the Switch Software Release Notes)

Compatible MGX 8850 Release 2:

MGX 8850 Release 2.0.15

Network Management Software:

10.5 (Refer to the CWM 10.5 Release Notes)



Note CWM 10.4.10 will support 1.1.4x baseline, but only when deployed with 1.1.34 features. CWM 10.4.10 also supports bug fixes in 1.1.4x baseline. CWM 10.5 supports features introduced in Release 1.1.40.


Boot File Names and Sizes

The following table displays the boot file names and sizes for this release.

File Name
File Size (in bytes)

ausm_8t1e1_AU8_BT_1.0.02.fw

377836

cesm_8t1e1_CE8_BT_1.0.02.fw

264592

cesm_t3e3_CE8_BT_1.0.02.fw

303936

frsm_8t1e1_FR8_BT_1.0.02.fw

297988

frsm_hs1_HS1_BT_1.0.02.fw

293052

frsm_vhs_VHS_BT_1.0.02.fw

467156

pxm_bkup_1.1.42.fw

1340740

rpm-boot-mz.122-4.T1

2621704

vism_8t1e1_VI8_BT_3.0.00.fw

248400


VISM and RPM Firmware Compatibility

The following table displays the VISM and RPM firmware compatibility matrix for this release.

PCB Descriptions
CW2000 Names
Latest F/W
Min F/W
File Name
File Size
(in bytes)

MGX-VISM-8T1
MGX-VISM-8E1

VISM-8T1
VISM-8E1

2.2

2.1(0)

vism_8t1e1_002.002.000.000.fw

3002488

MGX-RPM-128M/B
MGX-RPM-PR

RPM

12.2(4)T1

12.2(4)T1

rpm-js-m.z.122-4.T1 (IOS)

8584068


MGX 8250 and MGX 8850 Firmware Compatibility

The following table displays the MGX 8250 and MGX 8850 firmware compatibility matrix for this release.

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

PXM1

PXM-1

1.1.42

pxm_1.1.42.fw

2301668

PXM1-2-T3E3

PXM1-2T3E3

1.1.42

pxm_1.1.42.fw

2301668

PXM1-4-155

PXM1-4OC3

1.1.42

pxm_1.1.42.fw

2301668

PXM1-1-622

PXM1-OC12

1.1.42

pxm_1.1.42.fw

2301668

MGX-SRM-3T3/B

SRM-3T3

AX-CESM-8E1

CESM-8E1

10.0.23

cesm_8t1e1_10.0.23.fw

679744

AX-CESM-8T1

CESM-8T1

10.0.23

cesm_8t1e1_10.0.23.fw

679744

MGX-AUSM-8E1/B

AUSMB-8E1

10.0.24

ausm_8t1e1_10.0.24.fw

1197500

MGX-AUSM-8T1/B

AUSMB-8T1

10.0.24

ausm_8t1e1_10.0.24.fw

1197500

MGX-CESM-T3

CESM-T3

10.0.23

cesm_t3e3_10.0.23.fw

607600

MGX-CESM-E3

CESM-E3

10.0.23

cesm_t3e3_10.0.23.fw

607600

AX-FRSM-8E1/E1-C

FRSM-8E1

10.0.24

frsm_8t1e1_10.0.24.fw

825876

AX-FRSM-8T1/T1-C

FRSM-8T1

10.0.24

frsm_8t1e1_10.0.24.fw

825876

MGX-FRSM-HS2

FRSM-HS2

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2CT3

FRSM-2CT3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2T3E3

FRSM-2T3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2T3E3

FRSM-2E3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-HS1/B

FRSM-HS1/B

10.0.24

frsm_hs1_10.0.24.fw

755760


MGX 8230 Firmware Compatibility

The following table displays the MGX 8230 firmware compatibility matrix for this release.

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

PXM1

PXM-1

1.1.42

pxm_sc_1.1.42.fw

2300204

PXM1-2-T3E3

PXM1-2T3E3

1.1.42

pxm_sc_1.1.42.fw

2300204

PXM1-4-155

PXM1-4OC3

1.1.42

pxm_sc_1.1.42.fw

2300204

PXM1-1-622

PXM1-OC12

1.1.42

pxm_sc_1.1.42.fw

2300204

MGX-SRM-3T3/B

SRM-3T3

MGX-SRM-3T3/C

SRM-3T3

AX-CESM-8E1

CESM-8E1

10.0.23

cesm_8t1e1_10.0.23.fw

679744

AX-CESM-8T1

CESM-8T1

10.0.23

cesm_8t1e1_10.0.23.fw

679744

MGX-AUSM-8E1/B

AUSMB-8E1

10.0.24

ausm_8t1e1_10.0.24.fw

1197500

MGX-AUSM-8T1/B

AUSMB-8T1

10.0.24

ausm_8t1e1_10.0.24.fw

1197500

MGX-CESM-T3

CESM-T3

10.0.23

cesm_t3e3_10.0.23.fw

607600

MGX-CESM-E3

CESM-E3

10.0.23

cesm_t3e3_10.0.23.fw

607600

AX-FRSM-8E1/E1-C

FRSM-8E1

10.0.24

frsm_8t1e1_10.0.24.fw

825876

AX-FRSM-8T1/T1-C

FRSM-8T1

10.0.24

frsm_8t1e1_10.0.24.fw

825876

MGX-FRSM-HS2

FRSM-HS2

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2CT3

FRSM-2CT3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2T3E3

FRSM-2T3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-2T3E3

FRSM-2E3

10.0.24

frsm_vhs_10.0.24.fw

941076

MGX-FRSM-HS1/B

FRSM-HS1/B

10.0.24

frsm_hs1_10.0.24.fw

755760


Comparison Matrix

This multiservice gateway comparison matrix is designed to identify capabilities supported in the MGX 8220, 8230, 8250, and 8850 platforms.

Feature
MGX 8220
MGX 8230
MGX 8250
MGX 8850, PXM1
Slot Capacity
       

Total Number of Slots

16 single-height

14 single-height/
7 double-height, or combination

32 single-height/
16 double-height, or combination

32 single-height/
16 double-height, or combination

Slots for Processor cards (PXM1s)

2 single-height (plus 2 slots reserved for BNM)


2 double-height


2 double-height


2 double-height

Slots for Service Modules (SMs)

10 single-height

8 single-height/
4 double-height or combination

24 single-height/ 12 double-height, or combination

24 single-height/
12 double-height combination

Slots for SRM Cards

(Service Resource Modules)


2 single-height


2 single-height


4 single-height


4 single-height

 
Physical Attributes
8220
8230
8250
8850

Height (in inches)

8.75

12.25

26.25 to 29.75

26.25 to 29.75

Width (in inches)

17.45

17.72

17.72

17.72

Depth

20.0

23.5

21.5

21.5

 
Services
8220
8230
8250
8850

MPLS (IP +ATM)

No

Yes

Yes

Yes

Voice

No

Yes

Yes

Yes

ATM

Yes

Yes

Yes

Yes

Frame Relay

Yes

Yes

Yes

Yes

Frame Relay-to-ATM network interworking

Yes

Yes

Yes

Yes

Frame Relay-to-ATM service interworking

Yes

Yes

Yes

Yes

Circuit Emulation

Yes

Yes

Yes

Yes

 
Local Switching
8220
8230
8250
8850
 

No

Yes

Yes

Yes

 
Feeder
8220
8230
8250
8850

Feeder to BPX 8600

Yes

Yes

Yes

Yes

Feeder to MGX 8850 PXM-45

No

Yes

Yes

Yes

Feeder to IGX

No

Yes

No

No

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

No

Yes

Yes

Yes

 
Switching Capacity
8220
8230
8250
8850
 

320 Mbps

1.2 Gbps

1.2 Gbps

1.2 Gbps

 
Trunk/Port Interfaces
8220
8230
8250
8850

T3/E3

1

2
(one feeder trunk)

2
(one feeder trunk)

2

OC-3c/STM-1

1

4
(one feeder trunk)

4
(one feeder trunk)

4

OC-12c/STM-4

No

1

1

1

OC-48c/STM-16

No

No

No

No

n x T1/E1

Yes

Yes

Yes

Yes

 
Front Cards
8220
8230
8250
8850

AX-FRSM-8T1

Yes

Yes

Yes

Yes

AX-FRSM-8E1

Yes

Yes

Yes

Yes

AX-FRSM-8T1-C

Yes

Yes

Yes

Yes

AX-FRSM-8E1-C

Yes

Yes

Yes

Yes

MGX-FRSM-HS2

Yes

Yes

Yes

Yes

AX-FRSM-HS1

Yes

No

No

No

MGX-FRSM-HS1/B

Yes

Yes

Yes

Yes

MGX-FRSM-2T3/E3

No

Yes

Yes

Yes

MGX-FRSM-2CT3

No

Yes

Yes

Yes

AX-AUSM-8T1

Yes

No

No

No

MGX-AUSM-8T1/B

Yes

Yes

Yes

Yes

AX-AUSM-8E1

Yes

No

No

No

MGX-AUSM-8E1/B

Yes

Yes

Yes

Yes

AX-IMATM-8T1/B

Yes

No

No

No

AX-IMATM-8E1/B

Yes

No

No

No

AX-CESM-8T1

Yes

Yes

Yes

Yes

AX-CESM-8E1

Yes

Yes

Yes

Yes

MGX-CESM-T3E3

No

Yes

Yes

Yes

AX-SRM-T1E1/B

Yes

No

No

No

AX-SRM-3T3

Yes

No

No

No

MGX-SRM-3T3/B

Yes

Yes

Yes

Yes

MGX-SRM-3T3/C

Yes

Yes

Yes

Yes

MGX-VISM-8T1

No

Yes

Yes

Yes

MGX-VISM-8E1

No

Yes

Yes

Yes

MGX-RPM-128/B

No

Yes

Yes

Yes

MGX-RPM-PR

No

Yes

Yes

Yes

PXM1

No

Yes

Yes

Yes

PXM1-2T3E3

No

Yes

Yes

Yes

PXM1-4-155

No

Yes

Yes

Yes

PXM1-1-622

No

Yes

Yes

Yes

 
Back Cards
8220
8230
8250
8850

AX-SMB-8E1

Yes

Yes

Yes

Yes

AX-RJ48-8E1

Yes

Yes

Yes

Yes

AX-RJ48-8T1

Yes

Yes

Yes

Yes

AX-R-SMB-8E1

Yes

Yes

Yes

Yes

AX-R-RJ48-8E1

Yes

Yes

Yes

Yes

AX-R-RJ48-8T1

Yes

Yes

Yes

Yes

MGX-SCSI2-2HSSI/B

Yes

Yes

Yes

Yes

MGX-12IN1-4S

Yes

Yes

Yes

Yes

MGX-BNC-2T3

No

Yes

Yes

Yes

MGX-BNC-2E3

No

Yes

Yes

Yes

MGX-BNC-2E3A

No

Yes

Yes

Yes

MGX-BNC-3T3-M

No

Yes

Yes

Yes

PXM1-UI

No

Yes

Yes

Yes

MGX-MMF-4-155/B

No

Yes

Yes

Yes

MGX-SMFIR-4-155/B

No

Yes

Yes

Yes

MGX-SMFLR-4-155/B

No

Yes

Yes

Yes

MGX-SMFIR-1-622/B

No

Yes

Yes

Yes

MGX-SMFLR-1-622/B

No

Yes

Yes

Yes

MGX-RJ45-FE

No

Yes

Yes

Yes

MGX-MMF-FE

No

Yes

Yes

Yes

MGX-RJ45-4E

No

Yes

Yes

Yes


RPM Compatibility Matrix

MGX SW Version
1.1.3x
1.1.32
1.1.34
1.1.40
1.1.41/1.1.42

"Bundled" IOS SW version

12.1(3)T

12.1(5.3)T_XT

12.2(2)T2

12.2(4)T

12.2(4)T1

IOS Version

12.1(5.3)T_XT

12.1(5.3)T_XT

12.2(2)T2

12.2(4)T

12.2(4)T1

CWM

10.3

10.4.01

10.4.01 Patch 1

10.5

10.5


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, 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, see "Instructions to Abort PXM Upgrade" section. For more information, refer to Release Notes for Cisco WAN MGX 8850, MGX 8230 and MGX 8250 Software Version 1.1.40.

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.

Single PXM Installation Procedure


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. Use 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

Installation Procedure for Redundant PXMs

This section applies to upgrades from 1.1.23 and all later releases.


Caution Do not remove old firmware until the upgrade is done.


Note First you must ensure that the shelf IP address and the PXM IP address are set. The PXM must have its own unique IP address and there must be a another unique IP address for the shelf.


To set the PXM address, use the bootChange command:

        node-prompt> bootChange
        '.' = clear field;  '-' = go to previous field;  ^D = quit
        boot device          : lnPci 
        processor number     : 0 
        host name            : 
        file name            : 
        inet on ethernet (e) : 172.29.37.220:ffff00
        inet on backplane (b): 
        host inet (h)        : 
        gateway inet (g)     : 172.29.37.1
        user (u)             : 
        ftp password (pw) (blank = use rsh): 
        flags (f)            : 0x0 
        target name (tn)     : 
        startup script (s)   : 
        other (o)            : 

Set the "inet on ethernet (e) :" field with the first part of the entry (before the :) as the IP address, and the second part as the subnet mask.

Set the "gateway inet (g) :" with the gateway address.

This must be done on both PXMs. This can also be done in backup boot from the VxWorks prompt "->".

To set the shelf IP address:

node-prompt> cnfifip 26 shelf.ip.address subnet.mask broadcast.address

The second argument is the shelf IP address.

The third argument is the subnet mask.

The fourth argument is the broadcast address.


Step 1 Save your current configuration.

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.

Upgrade from Release 1.1.3x

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


Step 1 Enter abort <release no>

PXM.a> abort <release no>

Upgrade from Release 1.1.2x

If the upgrade needs to be aborted for any reason during the upgrade process, follow these instructions


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

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

b. On the Active PXM, enter shellConn

c. Enter smCardMibVer = 21

d. Enter saveDBToArchive <PXM SlotNo>, 0

e. Enter uploadBram <PXM SlotNo>, <PXM SlotNo>

For the MGX8850 Switch, the <PXM SlotNo> should be 7.

For the MGX 8250 Switch, use 7, even if the Active PXM is in slot 8.

For the MGX8230 Switch, the <PXM SlotNo> should be 1, even if the Active PXM is in slot 2.

The example that follows is for the MGX8850.

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

f. If RPM cards are also 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 will 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 2 Enter abort <release no>.
PXM.a> abort <release no>


Service Module Boot/Firmware Download Procedure

The following procedure describes how to download the service module firmware.


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 Enter the following command to download the boot image onto the respective service module:

install bt sm <slot #> <version>

Repeat for each of the service modules on the node.

Step 3 Choose the appropriate instruction for downloading slot-independent or slot-dependent firmware, as follows.

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 


Note 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: ipfrnj40 was running 1.1.24 as an 8850 node:

If the node's model number is set to 8250 by default after a 1.1.32 firmware upgrade, but the ipfrnj40 is still configured as a 8850 standalone node on the CWM side, then CWM will reject the node on discovery, and the node will remain undiscovered.

Solution: On every standalone node, manually verify that the runConfigurator settings match the switch.

Chassis Identification During a Firmware Upgrade

On the CWM side, the emd.conf must be modified to a one second wait time so it can help clean up the emc process's internal cache and CWM database (regarding any slot that has sent the functional removal trap). This ensures that CWM will sync up whatever is current with the switch after the upgrade.

Before a firmware upgrade is begun, complete the following steps:


Step 1 Change the following line in emd.conf:

"Hold for 300 secs before deleting the card after a func module trap is received".

to

"Hold for 1 secs before deleting the card after a func module trap is received".


Note This prevents race conditions in updating the database table from the firmware version upgrade.


Step 2 After emd.conf is changed, send HUP signals to all EMC processes.

Step 3 After the firmware upgrade is complete, reset the hold time back to 300 seconds.

Step 4 Send HUP signals to EMC processes to confirm the changeback.


Interoperability of Service Module on MGX 8220 and MGX 8850 Switches


Caution Graceful downgrade for Service Modules 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.

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 enter the command resetsys. Make sure that the configuration is saved.


Step 2 For non-graceful upgrades, just reset the card and the service module will come up with the new image.

Step 3 For graceful upgrades, a secondary card should be backing up the service module that needs to be upgraded. Configure the redundancy and issue the command:

install sm <slot> <version>

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

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


Note The concept of version is redundant here, since there is only one service module image on the disk. However we do check that the version given by the user matches the image on the disk to make it consistent with PXM upgrade/downgrade.


newrev sm <slot> <version>

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

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

commit sm <slot> <version>

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

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


Note There is no abort command for service module upgrade.


Route Processor Module (RPM) Addendum

This section describes the installation requirements and guidelines for RPM modules installed with this release.

All IOS firmware can be downloaded from CCO from the following location:

http://www.cisco.com/kobayashi/sw-center/sw-ios.shtml

About the CISCO IOS 12.2(4)T1 Release

The Cisco IOS 12.2(4)T1 is used with MGX Release 1.1.42. This IOS release supports existing features on the RPM-PR and MGX-RPM-128M/B cards.

About the Cisco IOS 12.2(4)T Release

The Cisco IOS 12.2(4)T or higher is used with MGX Release 1.1.40. This IOS release supports new RPM features and continues to support existing features on the RPM/PR and RPM/B cards.

Note that MPLS inter AS, MPLS TE, and POS port-adapter are not supported features on RPM for this release.

About the Cisco IOS 12.2(2)T2 and 12.2(2)T3 Release

The Cisco IOS 12.2(2)T2 and the 12.2(2)T3 Releases are used with MGX Releases 1.1.34 and 1.1.40. This IOS release does not support new RPM features, but has been tested with 1.1.34 and continues to support existing features on the RPM-PR and MGX-RPM-128M/B cards.

Please note the following anomaly in IOS Release 12.2(2)T2:

Problem Description:

Customers upgrading to 12.2(2)T2 image with RPMs might see some e-BGP sessions not coming up when the CE router is running an older version of IOS (12.0, 12.0.xT). This issue was first encountered with CE running 12.0(7)T image. In such cases, the CEs running old IOS versions were not able to create BGP sessions to PEs with the newer image (12.2(2)T2).

The issue is fixed in 12.2(2)T3. Customers who face the problems described with the 12.2(2)T2 image, may upgrade to 12.2(2)T3 image.

Symptom

MPLS PE doesn't advertise BGP network to CE router running an older IOS image

Conditions

A Cisco router that is running Cisco IOS Release 12.2(3.1)T or 12.2(2)T and is configured as a provider edge (PE) router may not support Label Distribution Protocol (LDP). This defect might cause the PE router not to advertise any Border Gateway Protocol (BGP) routes to a Cisco 2600 series customer edge (CE) router that is running Cisco IOS Release 12.0(18). However, the CE router will advertise routes to the PE router. Entering the neighbor ce-ipaddress don-capability-negotiate command on the PE router does not correct this defect.

Workaround:

Upgrade the CE router from Cisco IOS Release 12.0(18) to Cisco IOS Release 12.2(2)T3.

About the Cisco IOS 12.1(5.3)T_XT Release

The Cisco IOS 12.1(5.3)T_XT or higher is used with MGX Release 1.1.32 and provides support for:

RPM-PR in any MGX chassis
(Note: RPM-PR is FCS with Release 1.1.32; and General Availability with Release 1.1.34.)

RPM/Bs in an MGX 8230 chassis

Multiple RPM card types

IOS 12.1(5.3)T_XT offers no other software features for the RPM.


Note To locate IOS-related anomalies or problems fixed, please refer to IOS release notes.


Problems Fixed with IOS 12.1(5.3)T_XT

Please refer to the IOS 12.1 Release Notes at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121relnt/index.htm

Bypass Feature for RPM in 12.2(4)T IOS Release


Note Information about the bypass feature and the IOS commands used to support it was not available at the time of the printing of the RPM documents; therefore, it is included in the these release notes.


RPM cards have a maximum storage of 128 KB for the NVRAM. This size limitation creates a problem for customers with large configurations, who find it impossible to store the complete configuration in the NVRAM, even with compression enabled.

In order to support storage of large configuration files, a new bypass feature is now available in the 12.2(4)T IOS Release. With the bypass feature enabled, the enhanced "write memory" is used to bypass the NVRAM and save the configuration on:

For MGX Release 2, the file auto_config_slot## located in E:/RPM.

For MGX Release 1, the file auto_config_slot## located in C:/RPM.

Where"##" represents the zero-padded slot number in which the RPM card is seated in the MGX chassis.

To enable the bypass feature, issue the command rpmnvbypass from the IOS run time image—not in the IOS boot image.

To disable the bypass feature, issue the command no rpmnvbypass.

To verify that the bypass feature is either enabled or disabled, issue the show running-configuration command. If the bypass feature is enabled, rpmnvbypass is seen on the display. If it is not seen, the feature is not enabled.


Note Since the bypass feature bypasses NVRAM, it is not necessary to compress the configuration file using the command service compress-config.


Table 4 contains cautions important to the successful usage of the bypass feature.

Table 4 Boot Cautions

Caution
Why is This Important?

When using the bypass feature, you can only load the run time IOS image from the PXM hard-drive or from the boot flash.

In the case of an RPM module, the IOS image can be loaded in 3 ways:

1. From the PXM hard-drive.

2. From the boot flash.

3. From the network (e.g. via TFTP) from the RPM backcard (Ethernet or Fast Ethernet).

When the bypass feature is enabled, the "boot config" statement:

c:auto_config_slot## is automatically generated. The NVRAM configuration is cleared upon a "write memory". In order to load from the network, the RPM has to have an IP address for its backcard. This information is part of the NVRAM configuration, which was just cleared by enabling the bypass feature. Hence, it is not possible to load the IOS image from the network upon a reload of the RPM after the "rpmnvbypass" and "write memory" have been executed.

Do not enter the command no boot config because doing so may prevent the bypass feature from working properly.

When the bypass feature is enabled, the "boot config" statement:

c:auto_config_slot##

is automatically generated, and the NVRAM configuration is cleared.

Any writes now are directed to the "boot config" file. This is essential, as a "write memory" expects the "boot config" statement to be present.

If the "boot config" statement isn't present, it would write the configuration into the NVRAM, which of course, is not desirable when the objective is to save a complete configuration when the configuration is large and requires more space.

If the command write memory is issued with the bypass feature enabled, and is consequently followed by an RPM card reset, previous versions of the boot image will trigger the RPM card to go into boot mode (unable to load run-time IOS).

For safety purposes, the location of the system image is stored in a special area (called the ROMMON area) in the NVRAM. The ROMMON is always intact.

The 12.2(4)T boot image accesses and reads ROMMON in order to load the IOS image. Boot images prior to 12.2(4)T do not read the ROMMON area.

Generally, the IOS boot and run-time images are of the same versions. However, if the user changed his boot image to one prior to 12.2(4)T, on a reload, the boot image would see that the NVRAM configuration is empty (of course, this is normal when the bypass feature is enabled). However, since boot images prior to 12.2(4)T cannot access the ROMMON area, it cannot read there the location of the IOS image. Unable to see the IOS image, it instead loads itself.


Example 1 through Example 5 illustrate how the bypass feature is enabled and disabled, and how to validate each of these actions from the configuration display.

Example 1 Running configuration without the bypass feature enabled

rpm_slot02#show running-config
Building configuration...

Current configuration : 470 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rpm_slot02
!
boot system c:rpm-js-mz.122-3.6.T1
enable password cisco
!
ip subnet-zero
!
!
!
!
interface Switch1
 no ip address
 no atm ilmi-keepalive
 switch autoSynch off
!
ip classless
no ip http server
ip pim bidir-enable
!
!
snmp-server community public RO
snmp-server community private RW
!
!
line con 0
line aux 0
line vty 0 4
 no login
!
end

Example 2 Enable the bypass feature (rpmnvbypass)

rpm_slot02#
rpm_slot02#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
rpm_slot02(config)#rpmnvbypass
The "boot config" statement has been (re)added to your
runing configuration. Do not remove it else risk not
using the nvbypass feature

rpm_slot02(config)#end
rpm_slot02#

Example 3 Running configuration with bypass feature enabled (note rpmnvbypass at end of output)

rpm_slot02#show running-config
Building configuration...

Current configuration : 515 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rpm_slot02
!
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02    <==== Line added as per output above
enable password cisco
!
ip subnet-zero
!
!
!
!
interface Switch1
 no ip address
 no atm ilmi-keepalive
 switch autoSynch off
!
ip classless
no ip http server
ip pim bidir-enable
!
!
snmp-server community public RO
snmp-server community private RW
!
!
line con 0
line aux 0
line vty 0 4
 no login
!
rpmnvbypass
end

Example 4 Disable the bypass feature (no rpmnvbypass)

rpm_slot02#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
rpm_slot02(config)#no rpmnvbypass
rpm_slot02(config)#end
rpm_slot02#

Example 5 Running configuration after the bypass feature is disabled

rpm_slot02#show running-config
Building configuration...

Current configuration : 503 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname rpm_slot02
!
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02
enable password cisco
!
ip subnet-zero
!
!
!
!
interface Switch1
 no ip address
 no atm ilmi-keepalive
 switch autoSynch off
!
ip classless
no ip http server
ip pim bidir-enable
!
!
snmp-server community public RO
snmp-server community private RW
!
!
line con 0
line aux 0
line vty 0 4
 no login
!
end

rpm_slot02#

Refer to Route Processor Module (RPM) Addendum for more specific information about the RPM.

Upgrading from an RPM/B Card to an RPM-PR Card

To replace an RPM/B card with an RPM-PR card, the PXM must be running MGX Software Release 1.1.34 or later, and the RPM must be running IOS release 12.2(4)T or later. Then perform the following procedure.


Step 1 Insert the RPM-PR in a test node.

Step 2 Copy the new RPM-PR boot image to the flash. Verify that the boot image is the first file in the flash.

Step 3 Modify the configuration of the file to use the latest IOS image on the c: drive by entering the boot system c:<IOS_filename> command.

Step 4 Enter the write memory command to save the configuration file in NVRAM.

Step 5 Enter the show bootvar command to check the BOOT variable and to verify that the card us configured to boot from the latest image.

Now the RPM-PR card is ready to replace an RPM/B card.

Step 6 Verify the following before inserting the RPM-PR in the node:

PXM must be running a minimum firmware release of 1.1.34.

PXM disk contains the latest IOS image specified for the RPM-PR.



Caution Once an RPM/B card is replaced with a RPM-PR card, the RPM/B card can not be re-installed. If an attempt is made to re-install the RPM/B, the module will be put into 'Mismatch'.


Caution After installing the RPM-PR card, be sure not to mix card redundancy.

Booting the RPM

When the RPM is booted, the boot image must be the first file in the bootflash. If the bootflash does not have a valid boot image as a first file, the card may not be able to boot and can result in bootflash corruption. If the bootflash is corrupted, you will have to send the card back for an external burn with a valid boot image.

You can reboot the RPM from the PXM by entering the command resetcd <card_number> from the switch CLI, where card_number is the slot number of the RPM that is being rebooted.


Note Omitting the card number resets the entire system.


Also, you can reboot the RPM from the RPM using the RPM console port and entering the reload command.

Each time you turn on power to the RPM by inserting the RPM into the MGX 8850, it goes through the following boot sequence:

1. The RPM runs diagnostics on the CPU, memory, and interfaces.

2. The system bootstrap software, which is the boot image, executes and searches for a valid Cisco IOS image, which is the RPM runtime software.

The source of the Cisco IOS image is determined by the configuration register setting. To verify this setting, you can enter either the show version or show bootvar command.

If the configuration register is set to the factory-default setting of 0x01, RPM will come up and stay in boot mode.

If the configuration register is 0x2, the RPM will look for the runtime image either in bootflash or on the PXM C:RPM drive.

3. The search for runtime image is determined by which boot system command is entered.

Entering the boot system c:<runtime_image_name> command will result in a search for a runtime image on the PXM C:RPM drive.

Entering the boot system bootflash:<runtime_image_name> command will result in a search for a run time image in the bootflash.

4. If the runtime software is not found after three attempts, the RPM reverts to the boot mode.

5. If a valid Cisco IOS image is found, then the RPM searches for a valid configuration, which can reside in NVRAM or as a configuration file either on the PXM hard disk C: drive or in bootflash.

If you want to load from a specific configuration file, you should enter either the boot config bootflash:<config_file> command or the boot config c:<config_file> command.

6. For normal RPM operation, there must be a valid Cisco IOS image on the PXM C: drive or in bootflash, and a configuration in NVRAM or configuration file in bootflash or on the PXM disk.

The first time you boot the RPM, configure the RPM interfaces and save the configuration to a file in NVRAM. For information on the Cisco IOS instructions, refer to the link below:

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r21/rpm/21appc.htm

RPM Bootflash Precautions

The RPM bootflash is used to store boot image, configuration and "run time" files. The Flash stores and accesses data sequentially, and the RPM boot image must be the first file stored to successfully boot the card. Erasing the boot image or moving it from the first position on the Flash will cause the card to not boot.

The RPM boot image, which comes loaded on the Flash, will work for all RPM IOS images. Therefore, there is no reason to ever delete or move the factory installed boot image.


Note Erasing or moving the boot image can cause RPM boot failure. When this happens, the RPM must be returned to Cisco and re-flashed.


In order to avoid this unnecessary failure, requiring card servicing, you should

Never erase the boot file from the RPM Flash

Never change the position of the boot file on the RPM Flash

Use care when "squeezing" the Flash to clean it up.

As long as the boot file remains intact in the first position on the flash, the RPM will successfully boot.

Upgrading with 1:N Redundancy

The following procedure describes how to upgrade redundant RPM cards.


Note Redundancy must be established before you use this procedure.



Step 1 On the primary RPM card, upgrade the software. Refer to the 1.1.40 Version Software Release Notes Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Switches.


Tips Enter the copy run start command to save the configuration change.


Step 2 Switch to the secondary card using the softswitch command.

mgx8850a.7.PXM.a > softswitch <fromSlot> <toSlot>

This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded software defined in Step 1.

Step 3 After the secondary card is active, configure it to upgrade the software. (See Step 1.)

Step 4 Switch back to the primary card using the softswitch command.

This step makes the upgraded primary card active and resets the secondary card. When the reset is complete, the secondary card runs the upgraded software.

Step 5 If there are other primary cards with redundant (secondary) cards, repeat this procedure for each primary card.


Upgrading Non-redundant RPM-PR Cards

The following procedure describes how to upgrade non-redundant RPM-PR cards.


Step 1 Configure the RPM-PR card to store its configuration on the PXM hard disk by entering the boot config c:auto_config_<slot#> command or by saving it in NVRAM by entering the WR MEM command.

Step 2 Modify the running configuration to boot from the new upgrade software by entering the boot system command.

Step 3 Enter WR MEM to save the configuration.

Step 4 Reset the RPM-PR card by entering the reset command from the PXM or the reload command from the RPM-PR.


Historical Information from the 1.1.4x Baseline

Features Introduced in Release 1.1.40

Release 1.1.40 is a feature release. The following table contains a short description of the features which are available with Release 1.1.40.

Feature
IOS
CWM

16,000 Connections supported on the MGX 8230 and MGX 8250 Edge Concentrators

Not Required

10.5

ITU APS Annex A Compliance PXM1 (Limited Support)

Not Required

10.5

RPM Multi LVC Enables support for initiation of Multiple label switched paths (LSPs) per destination on the RPM.

12.2(4)T

RPM (RPMB/RPM-PR) 1:N RPM 1:N redundancy is used to switch configuration and traffic from one RPM module to another module.

12.2(4)T

10.5 (except for RPM/B; no CWM support for this module)

VISM 2.1(0) Support

12.1(5.3)T_XT

10.4.10 or higher

VISM 2.1(1) Support

12.2(4)T

10.5 or higher


16,000 Connections

This feature extends the current capabilities of the MGX8230 and MGX 8250 Edge Concentrators to increase the number of connections (PVC) on the PXM1 based PAR Controller from 12,000 to 16,000 connections.

If the MGX is a feeder to a BPX, only 15729 feeder connections are available. 271 connections are reserved for communication between the BPX and MGX.

The following table lists information about this new feature.

Compatibility
Limitations
Limits
CLI/MIB Changes

Switch Software Release 9.2.00 and higher

CWM 10.5 and higher

A downgrade from Release 1.1.40 should not be done after provisioning over 12,000 connections. If a downgrade occurs, connections above 12,000 are lost in the PAR database, and manual identification and deletion of the channels must be done from the service module.

Only after upgrading both the active and standby PXMs to Release 1.1.40 should provisioning for more than 12,000 connections be done.

BPX (with AR) software releases prior to 9.2.00 support only 12,000 connections; therefore, no more than 12,000 connections can be achieved with those releases.

Maximum number of PXM UNI connections supported is 4000 (as in prior releases).

None.


RPM Multi LVC

This IOS feature enables support for initiation of Multiple label switched paths (LSPs) per destination on the RPM. Up to four parallel LVCs are established per destination address and are set up dynamically between ELSR routers.

This feature enables interface level queueing rather than per-VC level on the RPM based on MPLS class of service policy. Different label switched paths are established for different class of services. This feature particularly benefits customers who wish to deploy IP VPN services in conjunction with Class of Service SLAs.

For more information about this feature, refer to the IOS document MPLS QoS Multi-VC Mode for PA-A3 at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/cos1221t.htm

The following table lists information about this new feature.

Compatibility
Limitations
Limits
CLI/MIB Changes

Switch Software Release 9.2.30 and higher

CWM 10.5 and higher

Although the architecture does not particularly limit the number of Multi-LVC connections a line card could support, the hardware of line cards set the limitation.

Up to four parallel LVCs are established per destination address.

None. All multicast connections are created or deleted by the MPLS signaling control plane through the VSI interface. Furthermore, the hardware configuration for multicast functionality is done in the system startup and requires no configuration parameters.


ITU APS

The following table lists information about this new feature.

Compatibility
Limitation
CLI/MIB Changes

CWM 10.5 and higher

Software

There is no support for 1:1. Release 1.1.40 supports only a 1+1 bidirectional non-revertive configuration. Further, Release 1.1.40 supports only the OC3/STM1 (SMFIR) interface. OC12/STM4 (SMFIR and SMFLR), and OC3/STM1 (SMFLR and MMF) will be supported in a future release.

Hardware

There is no support for intracard APS configuration.

Note The CLI command addaplsln may indicate support for the other 1+1 configuration options:

Unidirectional revertive

Unidirectional non-revertive

Bidirectional revertive and

However, these options have not yet been tested, and consequently, we do not support them in Release 1.1.40.

addapsln CLI modified

The parameter "archmode" sets the APS architect mode to be used on the working/protection line pairs. The new value "5" is added to specify 5: 1+1 Annex A.

dspapsln CLI modified


RPM (RPMB/RPM-PR) 1:N

RPM (RPMB/RPM-PR) 1:N redundancy feature is available on the MGX 8850, MGX 8230 and MGX 8250 switches. RPM 1:N redundancy is used to switch configuration and traffic from one RPM module to another module. The main benefits are:

If an RPM fails and there is no operator or there is no direct access to the failed RPM to swap the card or fix the problem. The RPM might have some hardware problems and the redundant standby card can take over the functionality while the RPM hardware problems are fixed.

Ease in Software upgrades without much down time.

The following table lists information about this new feature.

Compatibility
Limitations
CLI/MIB Changes

CWM 10.5 and higher

IOS 12.2(4)T

Hot Redundancy is not supported.

RPM's of the same card type can only participate in a redundancy group. i.e. RPM-B and RPM-PR cannot be redundant to each other.

Only the configuration of the failed/removed RPM card will be restored on the new card, not the state of the card.

Since the RPM provides layer 3 services and maintains routing tables for different protocols/technologies like BGP/OSPF/IS-IS/MPLS FIB tables etc., these won't be restored but will have to restart the learning process and build their tables after the standby comes up with the new configuration.

When a failed primary is replaced/recovered, the operator or network administrator has to manually switch from the secondary to primary to free up the secondary for future failures.

HSRP can be used for maintaining LAN routing redundancy but the ATM port adapter state or the switch side of the RPM, CLI, or SNMP-related data cannot be handled currently.

Layer 2 information like "inarp" tables that are created dynamically will also be lost.

Any PPP sessions that were terminated or transiting the RPM using L2TP/L2F tunnels will be restarted.


VISM Release 2.1(0) and Release 2.1(1) on MGX 8850 Release 1, MGX 8250, and MGX 8230

VISM Release 2.1(1) is a maintenance upgrade of VISM Release 2.1(0) and contains no new features. Both releases are compatible with MGX 8850 Release 1, MGX 8250, and MGX 8230 Release 1.1.40 software.

The VISM Release 2.1(1) is supported by the Cisco Voice Interworking Service Module Guide, which is available along with the VISM release notes on the Web at the following location:

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/

Problems Fixed in Release 1.1.40

Bug ID
Description

CSCds10286

Symptom:

The PXM displays the incorrect error message when trying to switch APS line using switchapsln CLI. The error message seen is "Manual Switching is blocked by SF or SD on PROT line" which is incorrect when the switch is being attempted from Protection line to working line.

Conditions:

An OC-12/OC3 trunk/line is configured as 1+1 unidirectional mode on the PXM. When the working line is in LOS and a MS APS switching request is made, the PXM incorrectly shows the request is blocked by SF or SD on protection line.

Workaround:

None. It is just erroneous message and it can be ignored.

CSCds20689

Symptom:

When the received traffic of the working line PXM connected to the BPX in APS 1+1 mode is restored, the BPX switches back immediately.

Conditions:

The restoration of the receive flow of the working line of the PXM.

Workaround:

None.

CSCds47676

Symptom:

When the clock level is configured to be STRATUM-3, the PXM trunk card does not receive the STRATUM-3 clock signal. The trunk card still gets the STRATUM-4 clock.

Conditions:

When the clock level is set as STRATUM-3, the STRATUM-3 clock signal does not output to the PXM trunk card. The PXM trunk card still gets the STRATUM-4 clock. However, the service modules do receive the STRATUM-3 clock.

Workaround:

No workaround currently.

CSCds48471

Symptom:

When an IMA port and ATM port are added in a AUSM card and ILMI is enabled on both, after ILMI failure clears, dspcd still shows Minor alarm with PORT ILMI fail.

Condition:

Happens on 5.0.13 AUSM firmware.

Workaround:

Execute find_out_port_fail_for_shelf_alarm under shellConn in AUSM. This will clear the problem.

CSCds58040

Symptom:

Cannot login to an 8250 switch using a newly created userid.

Conditions:

In 8250 switch releases 1.1.30 to 1.1.32, a new user account is created using the command adduser and subsequent command xcnfuser.

Workaround:

Create the new user account with the command adduser, then before the xcnfuser command is used for the newly created account, login using the new account from another terminal and logout.

CSCds90138

Symptom:

Upon receiving Path-RDI, the PXM status LED goes RED. No trap is generated. The alarm is reflected from the dspalm command display.

Conditions:

This symptom occurs when the Sonet line receives only Path-RDI alarm. Actually, this should happen in all versions of PXM prior to this fix version.

Workaround:

None.

CSCdt19187

Symptom:

The commands dspcons or dspchans increment the LocalVpIdNextAvailable by 2.

Conditions:

This problem occurs when the commands dspcons or dspchans are executed.

Workaround:

None. Not Service Impacting.

CSCdt28566

Symptom:

Frames are dropped due to port queue overflow without any frames being tagged on the egress direction. When the command dspchanct is executed for the channel, increasing values for FramesDiscarded count and FramesByteDiscarded in the transmit directions observed. When the command dspportcnt is executed for the port, increasing values for XmtFramesDiscXceedQDepth and XmtBytesDiscXceedQDepth in transmit direction are observed.

Conditions:

This problem occurs when the queue threshold for the port is configured very low.

Workaround:

Enter the command cnfegrq to configure the queue threshold accordingly. Note that in the case of Ratio Based Servicing, the high priority queue number is 1 and low priority is 2. In the case of WFQ, use the class of service index to refer to the queue number.

Verify that the values are set properly using the shellConn command eseQueInfoShow. This command takes two parameters—the port number and the queue number.

After setting the threshold to proper values, reset the card to get the changes into effect.

Further Problem Description:

The command cnfegrq does not update the cached copy of the port queue thresholds. Therefore, it is necessary to perform a reset to implement the new configuration. More over, the dspegrq command should be unblocked to make it available, irrespective of the type of servicing algorithm used in the card. Also, the command cnfegrq should be fixed to update the cached data structure and display proper queue numbers to use during different servicing algorithms.

CSCdt87411

Symptom:

With an MGX configured and connected to an External clock source it has been observed that on a switchcc, the newly active PXM fails the external clock and switches to the internal clock for up to 10 seconds.

Conditions:

This problem occurs when an external clock is configured on the node.

Workaround:

None.

Further Description:

This problem, in turn, creates errors on 64K, unrestricted data calls and could cause problems on high speed modem calls.

CSCdu14185

Symptom:

User is unable to add an RPM connection.

Conditions:

This problem occurs when using the CWM interface to add the RPM to RPM connection from MGX8250 to MGX8230.

Workaround:

Use Configuration Manager to add 3-segment connection: ATM(RPM) - ATM(RPM).

CSCdu17838

Symptom:

Line alarms clear after a card reset if lines are connected back to back on the same card.

Conditions:

This problem occurs only when 2 lines on the same card are connected back to back.

Workaround:

Up the other side of the lines and delete it.

CSCdu31948

Symptom:

When an ABR1 XPVC is provisioned via proxy across a hybrid network, from MGX1/AUSM-8T1 to MGX1/AUSM-8T1,the "egress service rate" is not configurable. The resultant default is a rate that limits the egress traffic, preventing the AUSM from attaining its PCR setting. Consequently, the PCR/MCR traffic management feature is compromised.

Conditions:

This occurs when AUSM-8T1/8E1 is provisioned as an endpoint of an XPVC connection for ABR1.

Workaround:

None.

CSCdu39315

Symptom:

Sometimes can't add more than 3000 connections.

Condition:

Dangling connection in the PAR database taking up the last entry in a connection block. System still thinks it has one more free entry in the connection block to allocate and hence allocation of new block is not triggered. In reality, we don't have a free entry anymore it has already been taken up by the dangling connection.

Workaround:

None.

CSCdu51930

Symptom:

Some 3-segment connections originating from a PXM UNI port stays in FAILED status after the system has been reset or after a power cycle.

Condition:

This problem occurs when the PAR receives an interface trap for the feeder interface before LMI channels are configured. This usually happens when there are lots of connections configured on the node.

Workaround:

Perform a switchcc on the PXM, or perform addlmiloop and dellmiloop on the PXM. Alternatively, perform cnfenhlmi to enable enhanced LMI for traffic passing through those connections.

CSCdu79008

Symptom:

T1 alarm counters are missing.

Conditions:

This problem is observed on the FRSM-8T1E1.

Workaround:

None.

CSCdu88301

Symptom:

On a FRSM-HS1/B card, in instances when traffic in excess of CIR is received from the network side, it causes egress buffer overflow. Consequently, this causes the card to reset.

Conditions:

This problem occurs only on the FRSM-HS1/B running with Version 10.0.22.

Workaround:

Egress data buffer overflow can be checked by using the shellConn command SarShow on the FRSM-HS1/B. An upgrade of the FRSM-HS1/B firmware to 10.0.23 resolves this problem.

CSCdu02695

Symptom:

When MGX is running on external clock and SM lines are set to local timing, we intermittently see slips on attached device interface even though both the attached device and the MGX show they are both taking clock from the same external source.

Conditions:

This happens when external clock is the current clock for the node.

Workaround:

If the external clock is disconnected and reconnected from the Active PXM UI card, the clock slips then stop and all is OK.

CSCdu12023

Symptom:

With a 120 ohms E1 clock source plugged into a PXM-UI= card (via RJ45 port), configuring the external clock type via the cnfextclk command to an incorrect value does not impair the clock source attached. The MGX still reflects the presence of the E1 external clock source when executing a dspcurclk command.

For example, configuring the external clock source type as T1, does not disturb the presence of the external E1 clock source physically plugged into the PXM-UI=. dspcurclk will continue to accept the external E1 clock source as the current clock, irrescpective of what is configured via the cnfextclk.

Conditions:

This Symptom occurs when an external Clock source is used.

Workaround:

None.

CSCdu27251

Symptom:

CESM card sometimes gets stuck in the failed state if a resetcd is done on it. The CESM may also go in the failed state if a cc is done to the card or the addcon command is executed on it.

Conditions:

This happens if the PXM has a UI-S3 back card and a switchcc is done. The shelf needs to be running on Stratum-3 level internal oscillator for this symptom to occur.

Workaround:

If the shelf is running on Stratum-3 level internal oscillator and there is a switchcc, re-execute the following command on the new active card:

cnfclklevel 3

Further Problem Description:

Please contact cisco TAC for a workaround referencing this bug id.

CESM shows up as failed on the PXM. A shellConn command scmConnShow will not show a connection built to the failed card.

In example:

-> scmConnSho scmConnShow 6

<SCM> Connection with standby PXM is up <SCM> Connection with SM 1 is up <SCM> Connection with SM 2 is up <SCM> Connection with SM 5 is up <SCM> Connection with SM 13 is up <SCM> Connection with SM 14 is up <SCM> Connection with SM 17 is up <SCM> Connection with SM 18 is up <SCM> Connection with SM 30 is up value = 1 = 0x1

Here we do not see the connection with SM 6 and this the card 6 (CESM) shows up as failed when you do a dspcds on the PXM.

CSCdu29422

Symptom:

The trap manager doesn't get deleted from the standby card.

Condition:

This symptom occurs on MGX Release 1 switches, Version 1.1.33Al. Trap managers are added; this gets updated on the standby, too. Upon aging, they are deleted only on the active card and not on the standby card. (On a switchcc, trap managers are seen as enabled, despite aging).

Workaround:

Not known.

CSCdu54264

Symptom:

The command switchapsln s x does not work.

Conditions:

This symptom occurs when APS is configured.

Workaround:

None.

CSCdu58229

Symptom:

The APS switches are working to protect on the BXM side but not on the PXM side.

Conditions:

This symptom occurs with the following combination: a BPX switch with APS configured as bidirectional, non revertive and a remote node on an MGX Release 1 PXM switch with the same APS configuration. The following sequence of events occurs:

1. Due to either a manual switch or a force switch, the protection line is the active line.

2. There is a fiber-cut/LOS on the receive side of protection line at the BPX end.

Workaround:

Perform an APS lock on the PXM and do an APS clear.

CSCdu58798

Symptom:

Following a replacement of the PXM card addcon fails when adding a connection between the PXM and an AUSM (other card types were not tried).

Conditions:

During automatic deletion (triggered by Resync) of a complete connection the Slave end is not deleted from the PAR database but was deleted from the SM/SPM database. This will disable the user from reading the slave connection.

Workaround:

None.

CSCdu62613

Symptom:

On a BPX switch (BXM), a clearing request APS Force W->P switches the active line to working.

Conditions:

This symptom occurs with a APS 1+1, bidirectional, non revertive configuration om a BXM connected to a PXM. In sequence, both nodes start on "protect" with no requests. On the PXM, a manual P->W. On a BXM, force W->P. On a BXM, clear requests.

Workaround:

Clear any request on PXM before issuing a request on the BXM.

CSCdu72190

Symptom:

On an active PXM, a reset occurs due to "Software Error Reset." The standby PXM took over, and there was no service impact.

Conditions:

This symptom occurs when CiscoView is running and SRM T3 lines are enabled. The time it takes for the PXM to reset depends upon the number of instances of CiscoView running. The PXM reset happens approximately every 4 hours when running more than 80 instances of CiscoView.

Workaround:

None.

CSCdu17049

Symptom:

On an MGX 8250 switch running Version 1.1.25, if an addcon is done on an RPM and the remote end of the connection is on port 256 of a FRSM-2CT3, the command is rejected with the following message:

Error:addcon:0:Connection add request to PXM failed.

If an attempt is made to add a connection from the RPM to a port numbered 255 or lower, the connection is added.

If an attempt is made to add a connection from another module, for example, an AUSM, to port 256 on the FRSM, the connection is added.

This problem is reproducible in version 1.1.32.

Conditions:

Connection is provisioned from RPM to FRSM-2CT3 with the port number on the FRSM as 256.

Workaround:

The current workaround is to use a port number less than 256 when adding connections between the FRSM-2CT3 and the RPM.

CSCdu32873

Symptoms:

The command dspnovram does not have options to dump SRM backcard information.

Conditions:

This symptom occurs in all versions where this command is implemented up to (not including) the version where this is fixed.

Workaround:

None.

CSCdu36455

Symptom:

After creating more than 20 users, some of the users encounter password corrupted.

Conditions:

This symptom occurs in instances when large number of users are added to the node.

Workaround:

None.

CSCdu42117

Symptom:

The command dsplog display the following message:

Unable to config requested clock source because clock source 8 is unknown.

Conditions:

This message is seen when the clock source or the node changes.

Workaround:

None.

CSCdu62281

Symptom:

The command dspnovram 1 bkpl command fails on an MGX 8230 switch with Translation Lookaside Buffer (TLB) exception.

Conditions:

This symptom occurs when executing the dspnovram command.

Workaround:

None.

CSCdu63686

Symptom:

The port M32EgressQueThresh is not preset in the CF file. This impacts CWM.

Conditions:

This symptom occurs during a TFTP of.CF file.

Workaround:

None.

CSCdu74317

Symptom:

When sending SNMP queries to some par related objects, a memory leak occurs.

Conditions:

Always.

Workaround:

None.

CSCdu83011

Symptom:

The misleading message:

"possible red table corruption"

is displayed when trying to do a softswitch.

Conditions:

Message is displayed when the redundancy card is cover card A and a softswitch it tried from card B to the redundant card.

Workaround:

None. No actual impact. other than the warning message creating confusion.

CSCdv00405

Symptom:

The LMI protocol version negotiation is unsuccessful between MGX2 and MGX1; however, this is not detected by the system.

Conditions:

The symptom occurs when MGX Release 2 initiates LMI version negotiation with a version other than 0, 1, 2 or 3 with MGX Release 1. MGX Release 1 will acknowledge this version, even though it does not support it. MGX Release 1 supports LMI version 0,1, 2 and 3 at this point in time.

Workaround:

None.

CSCdv04213

Symptom:

1. Both the primary and the secondary cards are in active state.

2. The secondary card is locked, and unable to change card to the card.

3. The line on CESM T3 generates alarms.

Conditions:

This symptom occurs when a "softswitch" is done from primary (active) to the secondary (stdby), followed by a reset of the active (secondary).

Workaround:

Unknown.

CSCdv08621

Symptom:

IP connectivity to the Release 1 MGX switch node stops working.

Conditions:

IP connectivity is via a PVC configured between a UNI port and 7.34 on the PXM.

Workaround:

Delete the connection and read it.

CSCdv44080

Symptoms:

Delete sub-interface from RPM using "no int sw1.xxx". But it will reappears in PXM Database after the periodic bulk update.

Condition:

When the sub-interfaces gets deleted on the RPM, it will also remove that sub-interface's entry from PXM database. But the periodic bookplate (sent every 2 hours by RPM to PXM) will update the PXM database with wrong data about this deleted sub-interface. After the bulk update, PXM database will show that sub-interface exists (in PXM database) but in reality it won't exist on the RPM. CWM RPM port table will also show this inconsistency.

Workaround:

None.


Obtaining Documentation

The following sections explain how to obtain documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL:

http://www.cisco.com

Translated documentation is available at the following URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.

You can e-mail your comments to bug-doc@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

Streamline business processes and improve productivity

Resolve technical issues with online support

Download and test software packages

Order Cisco learning materials and merchandise

Register for online skill assessment, training, and certification programs

You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:

http://www.cisco.com

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:

http://www.cisco.com/register/

If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:

http://www.cisco.com/tac/caseopen

If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.