Table Of Contents
Release Notes for Cisco WAN MGX 8850 Release 1, MGX 8250, and MGX 8230 Software Version 1.1.41
Contents
About These Release Notes
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.41
Known Anomalies for Platform Software Release 1.1.41 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.41
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.41, 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.41
Release 1.1.41 is a maintenance release that supports 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 and Release 1.1.41, 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 >
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.
Step 2 Verify that the two checksums are the same.
If not, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Caution If the checksums are not the same when you remove the service module, then the service module will not boot when it is plugged in and the service module will have to be returned using the Cisco Returned Material Authorization process.
Whenever an MGX 8850 is added as a feeder to a BPX 8600, SWSW automatically programs a channel with a VPI.VCI of 3.8 for use as the IP Relay channel. IP Relay is used to send IP data between nodes via the network handler, allowing every node in the domain to be directly addressable via IP addressing and CWM workstations to communicate with every node (especially feeders) using TELNET, SNMP and CWM protocols. If the user tries to add a channel with a VPI.VCI of 3.8, the BPX 8600 does not prevent the user channel from being added, but the MGX 8850 rejects it. To delete the added channel on the BPX 8600, and to get IP relay working you need to reset the BXM card.
In addition to clearing the entire configuration, 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.
- Only enter the ethernet IP address, netmask and default gateway.
- Type "." to erase incorrect entries.
tigers.1.7.PXM.a > bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
host name :C <-- Please put "C".
inet on ethernet (e) :172.29.37.40:ffffff00 <-- Ethernet IP Addr/Netmask
gateway inet (g) :172.29.37.1 <-- Default Gateway
ftp password (pw) (blank = use rsh):
- Type in reboot, after this the command "ping" will work as follows:
tigers.1.7.PXM.a >ping 171.71.54.53 1
Service module upgrades error handling is not provided. If the user skips any of the steps during upgrade or if a power failure happens in the middle of the upgrade, results will be unpredictable. See the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.
The MGX 8850 supports 15 simultaneous Telnet sessions and 10 TFTP sessions.
You must use the following Y-cables for FRSM-HS2 and FRSM-CT3 redundancy as specified in the Product Orderability Matrix (Straight Cable: 72-0710-01, Crossover Cable: 72-1265-01, Straight Y-cable: FRSM-HS2: CAB-SCSI2-Y, FRSM-CT3: CAB-T3E3-Y). Other cables are not supported.
Y-cable redundancy for FRSM-HS2, FRSM-2CT3, FRSM-2T3, FRSM-2E3 is supported only for adjacent slots.
There is no need to 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
|
"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.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.41 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.1.41 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.41
|
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.41.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.41
|
pxm_1.1.41.fw
|
2301668
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.1.41
|
pxm_1.1.41.fw
|
2301668
|
PXM1-4-155
|
PXM1-4OC3
|
1.1.41
|
pxm_1.1.41.fw
|
2301668
|
PXM1-1-622
|
PXM1-OC12
|
1.1.41
|
pxm_1.1.41.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.41
|
pxm_sc_1.1.41.fw
|
2300204
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.1.41
|
pxm_sc_1.1.41.fw
|
2300204
|
PXM1-4-155
|
PXM1-4OC3
|
1.1.41
|
pxm_sc_1.1.41.fw
|
2300204
|
PXM1-1-622
|
PXM1-OC12
|
1.1.41
|
pxm_sc_1.1.41.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
|
"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.
Step 2 Get the filename by listing the CNF directory:
-------- ------ ------ --------
512 APR-08-1999 08:16:18 . <DIR>
512 APR-08-1999 08:16:18 .. <DIR>
512 APR-09-1999 05:26:42 TMP <DIR>
45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip
45433 APR-09-1999 05:28:42 NODENAME.zip
total space : 819200 K bytes
free space : 787787 K bytes
Step 3 On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp shelf.ip.address
tftp> get CNF/NODENAME_0409990528.zip
Received 45433 bytes in 0.4 seconds
Step 4 Download the release to upgrade PXM Backup boot image to the PXM . For example:
unix-prompt> tftp <node_name or IP address>
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
Step 5 Download the release to upgrade PXM runtime image to the PXM. For example:
tftp> <node_name or IP address>
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
Step 6 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Use the TFTP put command:
tftp <node_name or IP address>
Step 7 On the PXM type the following when the transfer is done:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 8 Enter install bt <new_rel>.
Step 9 Enter install <new_rel>. At the end of the display, enter yes.
redundancy is not available
the other card is not available
you are not in redundant mode,
do you want to try an ungraceful upgrade
Installation Procedure for Redundant PXMs
This section applies to upgrades from 1.1.23 and all later releases.
Caution Do not remove old firmware until the upgrade is done.
Note First you must ensure that the shelf IP address and the PXM IP address are set. The PXM must have its own unique IP address and there must be a another unique IP address for the shelf.
To set the PXM address, use the bootChange command:
'.' = clear field; '-' = go to previous field; ^D = quit
inet on ethernet (e) : 172.29.37.220:ffff00
gateway inet (g) : 172.29.37.1
ftp password (pw) (blank = use rsh):
Set the "inet on ethernet (e) :" field with the first part of the entry (before the :) as the IP address, and the second part as the subnet mask.
Set the "gateway inet (g) :" with the gateway address.
This must be done on both PXMs. This can also be done in backup boot from the VxWorks prompt "->".
To set the shelf IP address:
node-prompt> cnfifip 26 shelf.ip.address subnet.mask broadcast.address
•The second argument is the shelf IP address.
•The third argument is the subnet mask.
•The fourth argument is the broadcast address.
Step 1 Save your current configuration.
Step 2 Get the filename by listing the CNF directory:
-------- ------ ------ --------
512 APR-08-1999 08:16:18 . <DIR>
512 APR-08-1999 08:16:18 .. <DIR>
512 APR-09-1999 05:26:42 TMP <DIR>
45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip
45433 APR-09-1999 05:28:42 NODENAME.zip
total space : 819200 K bytes
free space : 787787 K bytes
Step 3 On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp shelf.ip.address
tftp> get CNF/NODENAME_0409990528.zip
Received 45433 bytes in 0.4 seconds
Step 4 Verify that one PXM is Active and the other Standby.
Step 5 From the workstation, download the PXM Backup boot image.
unix-prompt> tftp pxm.ip.address
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
Step 6 From the workstation, download the PXM FW.
unix-prompt> tftp pxm.ip.address
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
Sent 1982672 bytes in 18.3 seconds
Make sure that the transfer is successful by looking at the message displayed on the PXM console after the transfer:
Calculated checksum = 0xd9779bc6 stored checksum = 0xd9779bc6
Note Bytes sent, program length, and receive time vary per release. Also, see the Compatibility Matrixes for current file sizes and file names.
Step 7 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Enter the TFTP put command:
unix-prompt> tftp <node_name or IP address>
Step 8 After the transfer is done, type the following on the PXM:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 9 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.
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.
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:
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> put <backup boot> POPEYE@SM_1_0.BT
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> put <FW file> POPEYE@SM_1_0.FW
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> 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 >
1tftp> put <boot filename> AXIS_SM_1_<slot#>.BOOTkj
Now you must insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Login to the shelf.
unix-prompt> tftp cc <slot #>
Verify that the two checksums are the same.
If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Service Module Upgrades
The following steps need to be followed for service module upgrades. Service module firmware images cannot be downloaded as specific versions, because only 1 slot independent image can be present on the disk. Hence, the user cannot revert back during the installation process.
Step 1 Download the service module firmware to the shelf. Refer to Service Module 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.41. 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:
is automatically generated, and the NVRAM configuration is cleared.
Any writes now are directed to the "boot config" file. This is essential, as a "write memory" expects the "boot config" statement to be present.
If the "boot config" statement isn't present, it would write the configuration into the NVRAM, which of course, is not desirable when the objective is to save a complete configuration when the configuration is large and requires more space.
|
If the command write memory is issued with the bypass feature enabled, and is consequently followed by an RPM card reset, previous versions of the boot image will trigger the RPM card to go into boot mode (unable to load run-time IOS).
|
For safety purposes, the location of the system image is stored in a special area (called the ROMMON area) in the NVRAM. The ROMMON is always intact.
The 12.2(4)T boot image accesses and reads ROMMON in order to load the IOS image. Boot images prior to 12.2(4)T do not read the ROMMON area.
Generally, the IOS boot and run-time images are of the same versions. However, if the user changed his boot image to one prior to 12.2(4)T, on a reload, the boot image would see that the NVRAM configuration is empty (of course, this is normal when the bypass feature is enabled). However, since boot images prior to 12.2(4)T cannot access the ROMMON area, it cannot read there the location of the IOS image. Unable to see the IOS image, it instead loads itself.
|
Example 1 through Example 5 illustrate how the bypass feature is enabled and disabled, and how to validate each of these actions from the configuration display.
Example 1 Running configuration without the bypass feature enabled
rpm_slot02#show running-config
Building configuration...
Current configuration : 470 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
snmp-server community public RO
snmp-server community private RW
Example 2 Enable the bypass feature (rpmnvbypass)
rpm_slot02#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
rpm_slot02(config)#rpmnvbypass
The "boot config" statement has been (re)added to your
runing configuration. Do not remove it else risk not
using the nvbypass feature
Example 3 Running configuration with bypass feature enabled (note rpmnvbypass at end of output)
rpm_slot02#show running-config
Building configuration...
Current configuration : 515 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02 <==== Line added as per output above
snmp-server community public RO
snmp-server community private RW
Example 4 Disable the bypass feature (no rpmnvbypass)
rpm_slot02#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
rpm_slot02(config)#no rpmnvbypass
Example 5 Running configuration after the bypass feature is disabled
rpm_slot02#show running-config
Building configuration...
Current configuration : 503 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02
snmp-server community public RO
snmp-server community private RW
Refer to Route Processor Module (RPM) Addendum for more specific information about the RPM.
Upgrading from an 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.
Feedback
