Table Of Contents
Release Notes for Cisco WAN MGX 8850
Release 1, MGX 8230, and MGX 8250 Software Version 1.2.00
Contents
Features Introduced in Release 1.2.00
FRSM-HS2/B
SRM-E
ITU APS Annex-A, All Configurations Supported on PXM1
CESM 8T1 Model B
PXM-UI-S3
VISM Release 2.2 on MGX 8250, MGX 8850 Release 1, and MGX8230 Switches
Features Not Supported in This Release
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
Service Module Redundancy Support
Network Management Features
Port/Connection Limits
SNMP MIB
Notes and Cautions
Loopback Plug on a HSSI:DTE Interface
UPC Connection Parameters
ForeSight and Standard ABR Coexistence Guidelines
CLI Modifications in 1.2.00 Baseline
Node Related
Connection Management Related
RPM Related
RPM Front Card Resets on the Back Card Removal
RPM-PR Back Ethernet Card Support
MGX-RPM-128M/B Ethernet Back Card Support
Limitations
CWM Recognition of RPM-PR and MGX-RPM-128M/B Back Cards
clrsmcnf
Problems Fixed in Release 1.2.00
Known Anomalies for Platform Software Release 1.2.00 and Service Module Firmware
Compatibility Notes
MGX 8230/8250/8850 Software Interoperability with Other Products
Boot File Names and Sizes
VISM and RPM Firmware Compatibility
MGX 8250/8850 Firmware Compatibility
MGX 8230 Firmware Compatibility
Comparison Matrix
RPM Compatibility Matrix
Special Installation and Upgrade Requirements
Special Instructions for Networks Containing FRSM 2 CT3
Executing the Script
Script Functionality
Single PXM Installation Procedure
Installation Procedure for Redundant PXMs
Instructions to Abort PXM Upgrade
Upgrade from Release 1.1.3x
Upgrade from Release 1.1.2x
Service Module Boot/Firmware Download Procedure
Manual Configuration of Chassis Identification
MGX as a Standalone Node
Chassis Identification During a Firmware Upgrade
Interoperability of Service Module on MGX 8220 and MGX 8250 Switches
Service Module Upgrades
Route Processor Module (RPM) Addendum
About the CISCO IOS 12.2(4)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 MGX-RPM-128M/B Card to an RPM-PR Card
Booting the RPM
RPM Bootflash Precautions
Upgrading with 1:N Redundancy
Upgrading Non-redundant RPM-PR Cards
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Cisco TAC Web Site
Cisco TAC Escalation Center
Release Notes for Cisco WAN MGX 8850
Release 1, MGX 8230, and MGX 8250 Software Version 1.2.00
Contents
Features Introduced in Release 1.2.00
Release 1.2.00 is a feature release. The following table contains a short description of the features which are available with Release 1.2.00.
Features
|
FRSM-HS2/B. In addition to the current HSSI interface support, the new service module supports V.35 and X.21 Frame Relay interfaces.
|
SRM-E Service Redundancy Module is an enhanced version of the current SRM-3T3 card, supporting a new one-port OC3/STM1 back card. The new card supports BERT, 1:N redundancy for the 8 port service modules and both T1 and E1 bulk distribution for the 8 port service modules. APS support will be available in a future release.
|
ITU APS Annex-A, All Configurations Supported on PXM1. This feature was introduced in Release 1.1.40 with some configurations supported; now all are supported. Compatible with CWM 10.5 and higher.
|
CESM 8T1 Model B eliminates problem in DS0 throughput reduction when CESM channels are configured in CAS mode (not applicable for E1 lines).
|
PXM-UI-S3, provides support for Stratum-3 clocking. This card was first supported in Release 1.1.31. Release 1.1.31 was compatible with CWM 10.3. The upgrade to Release 1.2.00 provides important fixes to this feature.
|
FRSM-HS2/B
The FRSM-HS2/B service module supports v.35 and x.21 frame relay interfaces in addition to the current HSSI interface. A new 8 port back card 12IN1-8S is introduced. The new front card supports the current HSSI back card and the new 12IN1-8S back card. All the current FRSM-HS2 features are supported in addition to the FRSM-HS1/B features. Each interface in the 12IN1-8S can be individually configured as x.21 or v.35 interface. The new service module supports a maximum of 4000 connections with the 12IN1-8S back card and 2000 connections with the HSSI back card when no LMI is configured. When LMI is configured, the maximum number of connections per port for strataLMI port is 560 and Annex A/D UNI/NNI port is 898.
The FRSM-HS2/B supports both DCE and DTE modes with line rates between 48Kbps to 51.84 Mbps for HSSI interface and 48Kbps to 8.192 Mbps for v.35/x.21 interface. In FRSM-HS2B, for DTE interfaces the clock frequency threshold %ge is introduced and is configurable (1 - 5) % with a default value of 3%. The new front card and back card is supported in CWM 10.5.10.
Warning Do not configure an interface to a DTE mode when a physical loopback plug is plugged in. This will cause the line to go in and out of alarm, and cause software errors in the PXM. Use the command cnfln to configure the line as DCE to recover from this situtation. For further information refer to bug CSCdv79470.
A comparison of the FRSM-HS1/B, FRSM-HS2, and FRSM-HS2/B is shown in Table 1.
Table 1 Comparison of FRSM Modules
Quality
|
FRSM-HS1/B
|
FRSM-HS2
|
FRSM-HS2/B
|
back card supported
|
12IN1-4S
|
HSSI
|
HSSI, 12IN1-8S
|
port count
|
4
|
2
|
2 with HSSI
8 with 12IN1-8S
|
maximum line rate
|
8 Mbps
|
52 Mbps
|
52 Mbps with HSSI
8 Mbps with 12IN1-8S
|
individually configurable interface type
|
No
|
No
|
No with HSSI
Yes with 12IN1-8S
|
DTE clock monitoring threshold
|
—
|
—
|
Available
|
maximum number of connections
|
200
|
2000
|
2000 with HSSI
4000 with 12IN18-S
|
redundancy support
|
No
|
1:1
|
1:1 with HSSI
None with 12IN1-8S
|
Table 2 CLI New or Modified Commands
CLI
|
Changes
|
addln
|
Existing addln command is modified to support per line interface type configuration (used only with the 12IN1-8S). If the user doesn't specify <interface_type>, the default type V.35 is used.
|
cnfln
|
Existing cnfln command is modified on FRSM-HS2/B to support new MIB objects.
Note Do not configure an interface to DTE mode when a physical loopback plug is plugged in. This will cause the line to go in and out of alarm and generate software errors on the PXM. If this situation occurs, use the command cnfln to configure the line as DCE to recover from the situtation. For further information about this problem, refer to the Known Anomalies for Platform Software Release 1.2.00 and Service Module Firmware, number CSCdv79470.
|
cnfclktype
|
Existing cnfclktype command is added to FRSM-HS2B to configure line clock type for V.35/X.21 interfaces. This command is valid on the FRSM-HS2B-12IN1 card.
|
dspln
|
Existing dspln command is modified on FRSM-HS2/HS2B to display new objects.
|
dsplns
|
Existing dsplns command is modified on FRSM-HS2/HS2B to display interface type.
|
The following table lists the cables necessary for card performance.
Table 3 Cables Supported for HSSI
DCE
|
DTE
|
Cable
|
FRSM-HS2/B
|
Cisco router
|
St. Cable 72-0710-01
|
FRSM-HS2/B
|
Non-Cisco standard DTE
|
St. Cable 72-0710-01
|
Cisco router
|
FRSM-HS2/B
|
St. Cable 72-0710-01
|
Non-Cisco standard DCE
|
FRSM-HS2/B
|
Cross Cable 72-1265-01
|
FRSM-HS2/B
|
FRSM-HS2/B
|
Cross Cable 72-1265-01
|
SRM-E
The new Service Redundancy Module is an enhanced version of the current SRM-3T3 card. The new card supports a one-port OC3/STM1 back card or functions without a back card.
Features Supported Without a Back Card
|
Features Supported With a Back Card
|
BERT
|
Bulk Distribution
|
1:N redundancy
|
BERT
|
--
|
1:N redundancy
|
The new card supports BERT, 1:N redundancy for the 8 port service modules and both T1 and E1 bulk distribution for the 8 port service modules. Support for both GR-253 and ITU- Annex A and B APS 1+1 will be provided in a future release.
The new front card will function without the back card for BERT and 1:N redundancy features. CWM and CiscoView will support the new front and back card.
You can have either 0, 2 or 4 SRM's with redundant processors and 0, 1 or 2 with non-redundant processors. The MGX8250 or MGX 8850 shelf has two bays while the MGX8230 has only one bay. Each bay of the MGX8x50 requires its own SRM-E card along with its respective back card. For full redundancy for the shelf, you need 4 SRM-Es and their respective back cards for MGX8850 or MGX 8250 switch (2 SRM-Es for MGX8230). Since the SRM-E is part of the core card set, if redundancy is required for the PXM, then redundancy also should be provided for the SRM-E.
SRM-E cards do not require any firmware to be downloaded to them. They are controlled by platform software running on the PXM. When a switch-over occurs from active PXM to standby PXM, the corresponding SRM-E cards (as part of the core card set) will also switch.
The interfaces available (through the appropriate back cards below) are:
· OC3 optical
· STS3 electrical
· STM1 optical
· STM1 electrical
The following cards are supported on both MGX8850 or MGX 8250 switch and the MGX8230 switch.
SMFIR: Single Mode Intermediate Range Fiber
STM1-EL-1: Synchronous Transport Module level 1
Limitations
|
Limits
|
Physical Interfaces
· Data Communication Channel (DCC) bytes in the Sonet/SDH overhead bytes are not supported.
· Byte-synchronous mapping will be implemented only for T1. Support for E1 will be implemented in a subsequent
phase only if required.
Bulk-mode Distribution
· Service module lines should be mapped to bulk-distributed channels on an all-or-none basis, i.e. a service module
should get all of its lines either from its back card or from the distribution bus but not both.
BERT
· When BERT is active, regular user traffic cannot flow on the port/line being tested.
· Only one BERT session per SRME can be active at any one time.
· You must stop an ongoing BERT operation to configure a different pattern.
· Far end loopbacks and V.54 polynomial loopbacks are not verified (they are always reported to have succeeded).
· if BERT is in progress, it will be stopped (and not resumed) if core card switch-over takes place.
· If BERT is in progress, it will be stopped (and not resumed) if APS switch-over is required.
· Only redundancy with 2 backcards is supported.
|
Bulk-mode distribution and redundancy
· A maximum of 84 T1 lines and 63 E1 lines can be distributed. Note that 12 slots are available in MGX8x50 for distribution with a capacity to support 96 T1/E1 lines if 8 line service modules are used.
· On MGX8x50, SRME in a given bay can distribute only to service modules in that bay.
· Only one set of service modules can be covered for redundancy in non-bulk mode using redundancy bus. (Multiple sets of service modules can be covered for redundancy in bulk mode)
· A redundancy group can not span both bays of MGX8x50.
Non-bulk mode redundancy
· Multiple redundancy groups can be defined but only one redundancy group in each half of the shelf can be using
the redundancy bus at any time.
BERT
· The BERT functionality described in this document is for use with the SRME card. The following Service Modules
are supported: FRSM-8T1/E1, AUSM-8T1/E1, CESM-8T1/E1, VISM-8T1/E1, FRSM-2CT3
· PN127 patterns are not supported because SRME can only generate the PN127 patterns and the detection is left to the service modules, which can not currently detect the PN127 patterns.
· BERT support in the service module is necessary. Service module must support specific services such as verify
the existence of a port/line, switch the physical lines to the BERT bus etc.
|
Automatic Protection Switching
· APS will be supported in a future release.
|
|
|
Table 4 SRM-E LED Descriptions
LED
|
State
|
Red
|
Yellow
|
Green
|
Off
|
ACT
|
Card State
|
N/A
|
N/A
|
Card is active and ready
|
Card is not yet ready
|
STDBY
|
Card State
|
N/A
|
Card is in standby mode or a mismatch occurred for active card
|
N/A
|
Card is not in standby mode or a mismatch did not occur for the active card
|
FAIL
|
Card State
|
Indicates a major failure with the card
|
N/A
|
N/A
|
Card is working
|
1:N RED
|
Card State
|
N/A
|
N/A
|
1:N on-bulk mode redundancy is in force
|
1:N on-bulk mode redundancy is not in force
|
BERT
|
Card State
|
N/A
|
N/A
|
BERT is in progress
|
BERT is not in progress
|
Line LED(s)
|
Line State
|
Service affecting alarms (LOS, LOF, LOP, AIS etc.)
|
Non-service affecting alarms (RDI)
|
Normal operation
|
Line is not connected
|
Table 5 SRM-E Commands
CLI
|
Change
|
addln
|
Physical interface. Existing command addln is modified to include interface type.
|
cnfln
|
Physical interface. Existing command cnfln is modified to support new MIB objects and new enumerations for line rate.
For tributary type, option VT2 (carries E1 signals in Sonet) is not supported in Release 1.2.00.
For tributary mapping type, only option, 2 byte-synchronous mapping, is supported for T1.
|
dspln
|
Physical interface. Existing command dspln is modified to include new MIB objects.
|
dsplns
|
Physical interface. Existing command dsplns is modified to the interface type.
|
delln
|
Physical interface. Existing command delln is modified to disable a line on the new card.
Note A line cannot be deleted if distribution links are configured for that line.
|
addlnloop
|
Physical interface. Existing command addlnloop is modified to add a logical loopback on a line on the new card.
|
dellnloop
|
Physical interface. Existing command dellnloop is modified command is modified to delete a logical loopback on a line on the new card.
|
cnfsrmclksrc
|
Managing clock sources. Existing command cnfclksrc is modified to configure a clock source on the new card.
Note If configured for loop timing and the clock is lost (say, due to LOS), SRM-E switches to the backplane clock and reverts to loop timing when the signal is restored. This protection feature is available only for loop timing.
|
dspsrmclksrc
|
Managing clock sources. Existing command dspsrmclksrc is modified to display the card types of the current and previous SRM card.
|
clralm
|
Managing alarms. Existing command clralm is modified to clear alarms on a line on the new card.
|
dspalm
|
Managing alarms. Existing command dspalm is modified to display alarms on a line on the new card.
|
dspalms
|
Managing alarms.Existing command dspalms is modified to display alarms on all lines of a slot on the new card.
|
clralmcnt
|
Managing alarms. The existing command clralmcnt is modified to clear alarm counts on a line on the new card.
|
dspalmcnt
|
Managing alarms.The existing command dspalmcnt is modified to display alarm counts on a line on the new card.
|
xcnfalm
|
Managing alarms.The existing command xcnfalm is modified to configure alarms for a line on the new card. The xcnfalm command allows only DS3 and E3 alarm thresholds to be configured.
|
dspalmcnf
|
Managing alarms.Display alarm configuration for a line.
|
addlink
|
Bulk redundancy/distribution. The existing command addlink is modified to link a certain number of T1/E1 channels from a bulk interface on SRM-E to a service module's T1/E1 lines. This command checks the card type of the service module in the target slot. The service module must be a T1/E1 type, depending upon the tributary type configured for the SRM-E line using the cnfln command. A service module will switch all its lines to bulk mode even if only one line is mapped to a tributary from SRM-E.
Note You must enable the lines on the SRM-E cards (using the upln and cnfln commands) before you can configure them for distribution.
|
cnflink
|
Bulk redundancy/distribution. The existing command cnflink is modified to configure the link for T1 byte-sync mapping on the new card. For byte-sync mapping on sonet interfaces, the T1 framing format should be configured.
The framing format can be specified at line level for all links using the cnfln command. It can be then overridden on a per link basis using the cnflink command.
Note The cnflink command is not applicable to 3T3 back cards. Also, byte-sync mapping is supported only for Sonet --> T1 mapping. Therefore, this command is not applicable if an SRM-E's line are configured for SDH --> E1 mapping.
|
dsplink, dspslotlink
|
Bulk redundancy/distribution. The existing commands dsplink/dspslotlink are modified to display distribution links on the new card.
|
dellink, delslotlink
|
Bulk redundancy/distribution. The existing commands dellink/delslotlink are modified to delete distribution links on the new card. After the last distribution link to a service module is deleted, the service module switches all its lines to non-bulk mode (to its back card).
|
clrsrmcnf
|
Managing configuration. The existing command clrsrmcnf is modified to clear all card configuration including distribution links. The configuration cannot be cleared if redundancy is enabled.
|
dspsrmcnf
|
Managing configuration. The existing command dspsrmcnf is modified to display the current card configuration.
|
addred
|
Redundancy activities. The existing command addred is modified to configure redundancy on the new card.
|
dspred
|
Redundancy activities. The existing command dspred is modified to display the redundancy configuration on the new card.
|
delred
|
Redundancy activities. The existing command delred is modified to delete the redundancy configuration on the new card.
|
softswitch
|
Redundancy activities. The existing command softswitch is modified to manually switch to the redundant module for the SRM-E.
|
switchback
|
Redundancy activities. The existing command switchback is modified to switch back to the primary module from the redundant module for the SRM-E.
|
cnfbert
|
BERT activities. The existing command cnfbert is modified to configure a line or port for BERT and start the test on the new card.
|
dspbert
|
BERT activities. The existing command dspbert is modified to display the parameters and the results of an ongoing operation on the new card.
|
modbert
|
BERT activities. The existing command modbert is used to modify BERT parameters.
|
delbert
|
BERT activities. The existing command delbert is modified to delete/terminate the operation in progress on the new card.
|
adddiagtest
|
Diagnostics.The following commands are modified for test number 8-SRM M13 Access. The commands will perform SRM or SRME hardware online diagnostics, depending upon what kind of cards are in the slot. Refer to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.1.40 at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/14/rnotes/rn1140.htm
|
clralldiagtests
|
Same as above.
|
clrdiagresults
|
Same as above.
|
cnfdiagparams
|
Same as above.
|
cnfdiagtest
|
Same as above.
|
deldiagtest
|
Same as above.
|
dspdiagtests
|
Same as above.
|
dspdiagresults
|
Same as above.
|
dsplog
|
The command dsplog will include SRME online diagnostics failure if it happens.
|
pausediag resumediag
|
Same as above.
|
rundiagtest
|
Same as above.
|
showdiagtests
|
Same as above.
|
ITU APS Annex-A, All Configurations Supported on PXM1
In the previous MGX1 release (1.1.40), limited ITU-APS Annex-A configuration was validated and made available in MGX 8230, 8250 and 8850 with support for a 1+1 bidirectional non-revertive configuration. In Release 1.2.00, the remaining configurations are supported.
Features
|
Limitations
|
Software
Supported configurations for OC3/STM1 (SMFIR) interface and OC12/STM4 (SMFLR and MMF) interface are:
•Bi-directional revertive
•Bi-directional non-revertive
•Unidirectional revertive
•Unidirectional non-revertive
|
Hardware
There is no support for intracard APS configuration.
Firmware
Interoperability between 1+1 unidirectional and 1+1 bidirectional is not supported.
|
Table 6 CLI Modified and New Commands
CLI
|
Change
|
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.
|
dspapsln
|
|
switchapsln
|
The command is modified to include the following options:
3 = forced working-> protection
4 = forced protection->working
5 = manual working->protection
6 + manual protection-> working
|
CESM 8T1 Model B
CESM-8T1 and CESM-8E1 cards provide TDM circuit emulation capabilities over ATM networks, according to ATM forum CES-IS standards.
During field testing, it was found that in the case of CESM-8T1 cards (and not applicable for CESM-8E1 cards), when a CESM channel was configured in CAS mode, the first byte of an AAL1 structure may not be aligned to the first byte of T1 physical level multiframe (SF/ESF). This causes the effective DS0 throughput to reduce from 62.67 Kbps to 60 Kbps. This throughput reduction causes bit errors when the CESM-8T1 is used in certain kind of applications; for example, during transfers of modem calls.
Both hardware and firmware changes were required to eliminate this anomaly. The hardware changes are implemented as CESM-8T1/B revision of the hardware with a minimum Firmware Release 1.2.00. No earlier versions of firmware are supported. The model "B" does not show up via CLI on the PXM or via CWM. However, if the command dspcd is executed from the CESM Model B, it will display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards. The CESM8T1/B card also is identified by a new face plate on which the card name is suffixed with a "B.".
Model A and Model B card are interchangeable, except when multi-framing is enabled on Model-B. In that case, multi-framing must be disabled before changing cards. Note that the default framing mode is non-multiframe (in order to have a compatibility between Model-A & Model-B).
The CESM8T1/B card supports 1:N redundancy.
Table 7 CESM-8T1 and CESM-8T1 /B Feature Comparison
CESM-8T1
|
CESM-8T1/B
|
Exhibits multiframe-AAL1 structure misalignment.
|
Multiframe-AAL1 structure aligned if MF enabled.
|
The clocking feature of deriving service module line clock can be used.
|
If MF is enabled, the service module line clock cannot be used to drive the PXM.
|
Ingress Cell Bus Slave FIFO reset in rare cases may not be synchronized to Cell Bus clock after switchcc.
|
Fixed FIFO reset logic in hardware (independent of software). This fixes the switchcc related problems.
|
Table 8 CLI Modified and New Commands
CLI
|
Change
|
dspcd
|
The dspcd command on the CESM model B card is modified to display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards.
CLI changes
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type and so on.
|
addcon and xcnfcon
|
Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.
|
PXM-UI-S3
Standard clocking in the MGX is supported with a built-in Stratum-4 clock source. For network applications that require a higher clock accuracy, the PXM-UI back card used with the Stratum-4 can be replaced with an optional PXM-UI-S3 back card that carries a Stratum-3 clock. This clock reference conforms to AT&T T1.5 and ITU G.824 specifications. A provision is also made for a Service Provider to connect an external clock source, if necessary.
The default clock is the internal Stratum-4. Pertinent CLI and MIB support are provided for Stratum-3 configuration. The PXM-UI-S3 back card is also recognized by the Cisco WAN Manager.
The Stratum-3 Clocking feature on the PXM-UI-S3 was introduced in Release 1.1.31, but support was removed in subsequent releases. It is being supported again in Release 1.2.00 and higher.
Hardware Changes
The new PXM-UI-S3 supports both T1 and E1 interfaces through an RJ-45/48 connector.
CLI
A new CLI cnfclklevel permits the user to set the STRATUM level desired.
Default Settings
VISM Release 2.2 on MGX 8250, MGX 8850 Release 1, and MGX8230 Switchest supported on the PXM-UI-S3 or this release. The external clock interace cannot be used for Stratum 4 with UIS3 backcard.
Warning If an External clock was configured to drive the node in Stratum-4 clocking with the old UI back card, and this UI card is replaced with the new PXM-UI-S3 back card, the Stratum-3 clocking must be explicitly configured on the node to continue using the External clock source. The following CLI's must be executed:
* cnfclklevel 3
* cnfextclk (with T1/E1 option)
VISM Release 2.2 on MGX 8250, MGX 8850 Release 1, 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 Release 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
Features Not Supported in This Release
•MPLS inter AS, MPLS TE, and POS port-adapter are not supported features on RPM.
•Layer 2 support as an AutoRoute routing node
•SRM T1E1
•Interworking with Cisco 3810
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
•The MGX-SRM-3T3-C front card replaces the original AX-SRM-3T3-A front card and the MGX-BNC-3T3 back card replaces the original AX-BNC-3T3 back card. Both the AX-SRM-3T3-A/AX-BNC-3T3 card set and the MGX-SRM-3T3-C/MGX-BNC-3T3 card set are supported on the MGX 8220.
•The AX-SCSI2-2HSSI is superseded by the MGX-SCSCI2-2HSSI/B, which works with the MGX-FRSM-HS2 and MGX-FRSM-HS2/B front card.
Service Module Redundancy Support
MGX 8850 provides high-speed native ATM interfaces, which can be configured as ATM UNI ports or trunks. The following table contains redundancy support information for service modules.
Table 9 Service Module Redundancy Support
Front Card Model #
|
Redundancy Supported
|
MGX-AUSM-8E1/B
|
1:N redundancy
|
MGX-AUSM-8T1/B
|
1:N redundancy
|
AX-CESM-8E1
|
1:N redundancy
|
AX-CESM-8T1
|
1:N redundancy
|
MGX-CESM-8T1/B
|
1:N redundancy
|
MGX-CESM-2T3E3
|
1:1 redundancy
|
AX-FRSM-8E1
|
1:N redundancy
|
AX-FRSM-8E1-C
|
1:N redundancy
|
AX-FRSM-8T1
|
1:N redundancy
|
AX-FRSM-8T1-C
|
1:N redundancy
|
MGX-FRSM-HS2
|
1:1 redundancy
|
MGX-FRSM-HS2/B
|
with HSSI back card, 1:1 redundancy with 12IN1-8S back card, no redundancy
|
MGX-FRSM-2CT3
|
1:1 redundancy
|
MGX-FRSM-2T3E3
|
1:1 redundancy
|
MGX-FRSM-HS1/B
|
No redundancy
|
MGX-RPM-128M/B
|
1:N redundancy
|
MGX-RPM-PR-256
|
1:N redundancy
|
MGX-RPM-PR-512
|
1:N redundancy
|
MGX-VISM-8T1
|
1:N redundancy
|
MGX-VISM-8E1
|
1:N redundancy
|
Note: Support for 1:N redundancy is provided in conjunction with an MGX-SRM-3T3 card or an MGX-SRM-E card.
|
Bulk Distribution is supported for T1 lines only on the SRM-3T3-C card.
Bulk Distribution is supported for T1 and E1 lines using the SRM-E card.
Network Management Features
Network management features are detailed in the CWM Release 10.5.10 Release Notes at: http://cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm
Port/Connection Limits
Connection limits can vary. The table below shows total connections per card, but also shows the number of connections per port with LMI enabled. For example, the new FRSM-HS2/B card using a HSSI back card can support a total of 2000 connections on the card. However, if LMI is enabled on both ports, the total number of connections goes down. If StrataLMI is enabled for one ports, that port supports 560 connections. The other port not configured for LMI can support 1000 connections, for a total of 1560 connections.
Overall, there is a limit of 16,000 connections per shelf.
Refer to Table 10 for detailed connection information.
Table 10 Port/Connection Limits
Card Type
|
Back Card(s)
|
Conns./Card
|
Physical Ports
|
Logical Ports
|
Per port with StrataLMI
|
Per port with Annex A/D NNI/UNI
|
MGX-FRSM-HS2/B
|
HSSI
|
2000
|
2
|
2
|
560
|
898
|
|
12IN1-8S
|
4000
|
8
|
8
|
560
|
898
|
MGX-FRSM-HS2
|
HSSI
|
2000
|
2
|
2
|
560
|
898
|
MGX-FRSM-2CT3
|
BNC-2T3
|
4000
|
2
|
256
|
560
|
898
|
MGX-FRSM-2T3E3
|
BNC-2T3
|
2000
|
2
|
2
|
560
|
898
|
|
BNC-2E3
|
2000
|
2
|
2
|
560
|
898
|
|
BNC-2E3A
|
2000
|
2
|
2
|
560
|
898
|
MGX-FRSM-HS1/B
|
12IN1-4S
|
200
|
4
|
4
|
200
|
200
|
MGX-AUSM-8E1/B
|
RJ48-8E1
|
1000
|
8
|
8
|
N/A
|
N/A
|
|
SMB E1
|
1000
|
8
|
8
|
N/A
|
N/A
|
MGX-AUSM-8T1/B
|
RJ48-8T1
|
1000
|
8
|
8
|
N/A
|
N/A
|
AX-CESM-8E1
|
RJ48-8E1
|
248
|
8
|
248
|
N/A
|
N/A
|
|
SMB-8E1
|
248
|
8
|
248
|
N/A
|
N/A
|
AX-CESM-8T1
|
RJ48-T1
|
192
|
8
|
192
|
N/A
|
N/A
|
MGX-CESM-8T1/B
|
RJ48-T1
|
192
|
8
|
192
|
N/A
|
N/A
|
MGX-CESM-2T3E3
|
BNC-2T3
|
1
|
1
|
1
|
N/A
|
N/A
|
|
BNC-2E3
|
1
|
1
|
1
|
N/A
|
N/A
|
AX-FRSM-8E1
|
RJ48-8E1
|
1000
|
8
|
8
|
560
|
898
|
|
SMB-8E1
|
1000
|
8
|
8
|
560
|
898
|
AX-FRSM-8E1-C
|
RJ48-8E1
|
1000
|
8
|
192
|
560
|
898
|
|
SMB-8E1
|
1000
|
8
|
192
|
560
|
898
|
AX-FRSM-8T1
|
RJ48-8T1
|
1000
|
8
|
8
|
560
|
898
|
AX-FRSM-8T1-C
|
RJ48-8T1
|
1000
|
8
|
192
|
560
|
898
|
•For the MGX8230 and MGX 8250 Edge Concentrators, 16,000 connections (PVC) on the PXM1 based PAR Controller. If the MGX is a feeder to a BPX, only 15,729 feeder connections are available—271 connections are reserved for communication between the BPX and MGX. Maximum number of PXM UNI connections supported is still 4000 (as in prior releases).
SNMP MIB
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 and new_mibFormat. The old_mib_Format is going to be discontinued in a future release.
Notes and Cautions
The following notes and cautions should be reviewed before using this release.
Loopback Plug on a HSSI:DTE Interface
Using a loopback plug on a HSSI:DTE interface is not supported and can bring the node down. Please refer to CSCdv79470 in the Known Anomalies for Platform Software Release 1.2.00 and Service Module Firmware, for more information about this anomaly.
UPC Connection Parameters
In Release 1.1.40 and higher, the default PCR is 50 cps, and the default for policing is "enabled." These settings are insufficient for running RPM ISIS protocol over the connection, and with such settings, the ISIS protocol will fail. The PCR value needs to be increased, depending upon the number of interfaces configured for ISIS on the RPM. CLI modification and changes in this release.
Depending upon your connection type, you can use the following CLIs to modify the PCR parameter.
•cnfupccbr
•cnfupcvbr
•cnfupcabr
•cnfupcubr
ForeSight and Standard ABR Coexistence Guidelines
ForeSight is similar to the rate-based ABR control system in TM 4.0 in that they both use Rate up and Rate down messages sent to the source of the connection to control the rate a connection runs at, based on congestion within the switches along that connections path. Both systems use Resource Management (RM) cells to pass these messages. There are differences between the two systems that need to be considered.
RM Cell Generation
ForeSight is a destination-driven congestion notification mechanism. The destination switch is responsible for generating the RM cells, which defaults to every 100 ms. This means that any rate modifications at the source end happen approximately every 100 ms, and the time delay between the actual congestion at the destination and the source getting to know about it could be 100 ms.
In standard ABR a source generates FRM cells every (nRM) cell intervals, where n is configurable. These are used to pass congestion information along to the destination switch, which then uses this information to generate BRM (Backward RM cells) back to the source A further consideration is that the actual user data flow will be lower for an equivalent rate due to the additional RM cells. Therefore, the more traffic being generated on a connection at any one time, the faster the feedback will be to the source.
There is also a TRM parameter which states that if no RM cells have been generated after this time has passed then one will automatically be sent. Depending upon the speed it is running at, an ABR connection may therefore react faster or slower to congestion than the equivalent ForeSight connection. (for example, if an ABR connection runs at 100 cells per second, and nRM is 32, then approximately three RM cells will be generated per second, or once every 300 msecs. If it runs at 1000 cps then an RM cell would be generated approximately every 30 msecs. In both cases, the equivalent ForeSight connection would generate an RM cell every 100 msec.)
Reaction to Feedback Messages - Rate Up
In ForeSight, in response to a Rate Up cell from the destination, the source increases its rate by a percentage of the MIR for that connection. If we call this percentage the rate increase percentage (RIP), then RIP is configurable at the card level (the default is 10 percent). In the case where MIR is low, the ForeSight rate increase will be slow as it has to increase as a percentage of MIR (rather than CIR).
On a standard ABR connection, in the event of available bandwidth (no congestion) the source increases its rate by a factor of (RIF*PCR). This means the rate increase step sizes are much bigger than for ForeSight for larger values of RIF (RIF has a range of 1/2, 1/4,....,1/32768). If RIF is not configured properly then standard ABR will ramp up its rate much faster and to a higher value. This is aided by the fact that the step sizes are bigger and the step frequency is higher in comparison with ForeSight.
Reaction to feedback messages - Rate Down
In ForeSight on receiving a Rate Down cell from the remote end, the source reduces its current rate (actual cell rate) by 13 percent. The rate decrease percentage (RDP). RDP is configurable at the card level.
In standard ABR, rate decrease is by an amount (RDF*ACR). Currently, the default value of RDF is 1/16 (6.25 percent). This means when this connection co-exists with ForeSight connections, in the event of congestion ForeSight connection reduces its rate by 13 percent whereas standard ABR connection reduces its rate by only 6.25 percent. Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types, then RDF should be changed to 1/8, so that both connections ramp down by the same amount (13 percent).
Fast-Down
In ForeSight if the destination egress port drops any data due to congestion then the destination sends a Fast Rate Down cell. Also, if a frame cannot be reassembled at the egress due to a lost cell somewhere in the network, a Fast-down will be generated. On reception of Fast Rate Down the source reduces its current rate by 50 percent (this is again a card-level configurable parameter).
Standard ABR does not distinguish between drops and the ECN/EFCI threshold being exceeded. This means that, in case of drops in the egress port queue, a standard ABR connection rate reduces by only (RDF*ACR) but the ForeSight connection rate reduces by (ACR*0.5). Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types then Fast Down could be effectively disabled by configuring the reaction to be 13 percent rate down instead of 50 percent.
Guidelines
The two systems will work together within the network, but as the above description suggests, if the differences between the two systems are not taken into consideration, then a ForeSight connection and an ABR connection with the same configuration parameters will not behave the same way within the network.
ABR and ForeSight provide a mechanism for distributing excess bandwidth between connections over and above the minimum rate, therefore if these guidelines are not taken into consideration then the allocation of this excess bandwidth may be biased toward connections running one of these algorithms over connections running the other.
If this is a requirement, the following guidelines may be useful, assuming ForeSight is set to defaults except for Fast Rate Down which is set for 13 percent.
1. Nrm: Nrm needs to be set at a value whereby the approximate RM cell generation is
100 milliseconds, to match that of ForeSight. This calculation is based on the expected average, or sustained, cell rate of the connection. However, if the (potential) fast-down messages from ForeSight are left to equate to 50 percent rate down, then an estimate of how often this may occur needs to be made and factored into the equation. If the connection receives Fast-down messages, then this would make the ForeSight connection react faster than the equivalent ABR connection to congestion. To compensate for this, Nrm needs to be set at a value of less than 100 msecs, a suggested value to aim for is between 60-70 msecs (this would be approximate as n is configurable in steps of 2**n). This would mean that, in the event of congestion, the ABR connection would start to react faster.
2. RIF: Rate increase factor is a factor of PCR in ABR and MCR in ForeSight. The default RIF for ForeSight is MCR*.10. Therefore, RIF should be configured so that (PCR*RIF) approximates MCR*0.1. If Fast-Down is still effectively enabled, then PCR*RIF should approximate MCR*0.62 to compensate.
3. RDF: (Rate Decrease Factor) RDF should be 1/8. This approximates to 13 percent that ForeSight uses.
The following worked examples may help explain this further
Assume a network is currently running ForeSight with default parameters, and supports the following four connection type, where CIR = MIR, PIR = port speed, and QIR = PIR:
T1 Port Speed 64K CIR
Example:
CIR = MIR = 64K
PIR = QIR = port speed = 1544
Fastdown = 13%
(The calculation used to convert between frame based parameters (CIR, PIR, and so on.) and their equivalent cell-based parameters is FR_param *3/800. This allows for cell overheads, and so on. based on frame sizes of 100 octets.)
CIR = MIR = (64000*3/800) = 240 cps
PIR = QIR = (1544 *3/800) = 5790 cps
ForeSight ABR
Rate-up equals (240*.1) = 24 cps RIF equals x where (1590/x) = 24 cps
X needs to be approx 200
RIF equals 256 (nearest factor of 2)
RDF equals 13% RDF = 1/8
Nrm equals 100 msecs Nrm equals 32
RM cells will be generated somewhere between 6 (5790 cps approx equal to 32 cells per 6 msecs) and 133 msecs (240 cps approx equal to 32 cells every 133 msecs) depending on ACR.
CLI Modifications in 1.2.00 Baseline
Table 11 lists the new and modified commands in Release 1.2.00 baseline.
Table 11 New/Modified CLI Commands in This Release
CLI
|
Changes
|
For Feature
|
addapsln
|
The parameter "archmode" sets the APS architect mode to be used on the working/protection line pairs. The new value "5" is added to specify 5: 1+1 Annex A.
|
ITU APS Annex-A
|
addcon
|
Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.
|
FRSM-HS2/B
|
adddiagtest
|
Diagnostics.The diagnostic commands are modified for test number 8-SRM M13 Access. This command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot. Refer to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.1.40 at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/14/rnotes/rn1140.htm
|
SRM-E
|
addlink
|
Bulk redundancy/distribution. The existing command addlink is modified to link a certain number of T1/E1 channels from a bulk interface on SRM-E to a service module's T1/E1 lines. This command checks the card type of the service module in the target slot. The service module must be a T1/E1 type, depending upon the tributary type configured for the SRM-E line using the cnfln command. A service module will switch all its lines to bulk mode even if only one line is mapped to a tributary from SRM-E.
Note You must enable the lines on the SRM-E cards (using the upln and cnfln commands) before you can configure them for distribution.
|
SRM-E
|
addln
|
Existing addln command is modified to support per line interface type configuration (used only with the 12IN1-8S). If the user doesn't specify <interface_type>, the default type V.35 is used.
|
FRSM-HS2/B
SRM-E
|
addlnloop
|
Physical interface. Existing command addlnloop is modified to add a logical loopback on a line on the new card. (SRM-E)
|
SRM-E
|
addred
|
Redundancy activities. The existing command addred is modified to configure redundancy on the new card.
|
SRM-E
|
clralldiagtests
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
clralm
|
Managing alarms. Existing command clralm is modified to clear alarms on a line on the new card.
|
SRM-E
|
clralmcnt
|
Managing alarms. The existing command clralmcnt is modified to clear alarm counts on a line on the new card.
|
SRM-E
|
cnfbert
|
BERT activities. The existing command cnfbert is modified to configure a line or port for BERT and start the test on the new card.
|
SRM-E
|
cnfclktype
|
Existing cnfclktype command is added to FRSM-HS2B to configure line clock type for V.35/X.21 interfaces. This command is valid on the FRSM-HS2B-12IN1 card. Command is valid on SRM-E.
|
FRSM-HS2/B
|
cnfdiagparams
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
clrdiagresults
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
cnfclklevel
|
Permits the user to set the STRATUM level desired. (S-3 Clocking)
|
PXM-UI-S3
|
cnfdiagtest
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
cnflink
|
Bulk redundancy/distribution. The existing command cnflink is modified to configure the link for T1 byte-sync mapping on the new card. For byte-sync mapping on sonet interfaces, the T1 framing format should be configured.
The framing format can be specified at line level for all links using the cnfln command. It can be then overridden on a per link basis using the cnflink command.
Note The cnflink command is not applicable to 3T3 back cards. Also, byte-sync mapping is supported only for Sonet --> T1 mapping. Therefore, this command is not applicable if an SRM-E's line are configured for SDH --> E1 mapping.
|
SRM-E
|
cnfln
|
Existing cnfln command is modified on FRSM-HS2/B to support new MIB objects.
Note Do not configure an interface to DTE mode when a physical loopback plug is plugged in. This will cause the line to go in and out of alarm and generate software errors on the PXM. If this situation occurs, use the command cnfln to configure the line as DCE to recover from the situation. For further information about this problem, refer to the Known Anomalies for Platform Software Release 1.2.00 and Service Module Firmware, number CSCdv79470.
For SRM-E, cnfln command is modified to support new MIB objects and new enumerations for line rate.
For tributary type, option VT2 (carries E1 signals in Sonet) is not supported in Release 1.2.00.
For tributary mapping type, only option, 2 byte-synchronous mapping, is supported for T1.
|
FRSM-HS2/B
SRM-E
|
cnfsrmcklsrc
|
Managing clock sources. Existing command cnfsrmclksrc is modified to support the new SRM-E card.
|
SRM-E
|
clrsrmcnf
|
Managing configuration. The existing command clrsrmcnf is modified to clear all card configuration including distribution links. The configuration cannot be cleared if redundancy is enabled.
|
SRM-E
|
delbert
|
BERT activities. The existing command delbert is modified to delete/terminate the operation in progress on the new card.
|
SRM-E
|
deldiagtest
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
dellink, delslotlink
|
Bulk redundancy/distribution. The existing commands dellink/delslotlink are modified to delete distribution links on the new card. After the last distribution link to a service module is deleted, the service module switches all its lines to non-bulk mode (to its back card).
|
SRM-E
|
delln
|
Physical interface. Existing command delln is modified to disable a line on the new card.
Note A line cannot be deleted if distribution links are configured for that line.
|
SRM-E
|
dellnloop
|
Physical interface. Existing command dellnloop is modified to delete a logical loopback on a line on the new card.
|
SRM-E
|
delred
|
Redundancy activities. The existing command delred is modified to delete the redundancy configuration on the new card.
|
SRM-E
|
dspalmcnt
|
Managing alarms.The existing command dspalmcnt is modified to display alarm counts on a line on the new card.
|
SRM-E
|
dspalm
|
Managing alarms. Existing command dspalm is modified to display alarms on a line on the new card.
|
SRM-E
|
dspalmcnf
|
Managing alarms.Display alarm configuration for a line.
|
SRM-E
|
dspalms
|
Managing alarms. Existing command dspalms is modified to display alarms on all lines of a slot on the new card.
|
SRM-E
|
dspapsln
|
|
ITU APS Annex-A
|
dspbert
|
BERT activities. The existing command dspbert is modified to display the parameters and the results of an ongoing operation on the new card.
|
SRM-E
|
dspcd
|
The dspcd command on the CESM model B card is modified to display "CESM8T1B" next to the Fab number. This can be used to differentiate between CESM model A and B cards.
CLI changes
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type and so on.
|
FRSM-HS2/B
|
dspdiagresults.
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
|
SRM-E
|
dspdiagtests
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot.
|
SRM-E
|
dsplink, dspslotlink
|
Bulk redundancy/distribution. The existing commands dsplink/dspslotlink are modified to display distribution links.
|
SRM-E
|
dspln
|
Existing dspln command is modified on FRSM-HS2 B and SRM-E to display new objects.
|
FRSM-HS2/B
SRM-E
|
dsplns
|
Existing dsplns command is modified to display interface type.
|
FRSM-HS2/B
SRM-E
|
dsplog
|
The command dsplog will include SRME online diagnostics failure if it happens.
|
SRM-E
|
dspred
|
Redundancy activities. The existing command dspred is modified to display the redundancy configuration on the new card.
|
SRM-E
|
dspsrmclksrc
|
Managing clock sources. Existing command dspsrmclksrc is modified to display the card types of the current and previous SRM card.
|
SRM-E
|
dspsrmcnf
|
Managing configuration. The existing command dspsrmcnf is modified to display the current card configuration on the new card.
|
SRM-E
|
modbert
|
BERT activities. The existing command modbert is used to modify BERT parameters.
|
SRM-E
|
pausediag resumediag
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
|
SRM-E
|
rundiagtest
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
|
SRM-E
|
showdiagtests
|
Command is modified for test number 8-SRM M13 Access. The command will perform SRM or SRM-E hardware online diagnostics, depending upon what kind of cards are in the slot
|
SRM-E
|
softswitch
|
Redundancy activities. The existing command softswitch is modified to manually switch to the redundant module for the SRM-E.
|
SRM-E
|
switchapsln
|
The command is modified to include the following options:
3 = forced working-> protection
4 = forced protection->working
5 = manual working->protection
6 + manual protection-> working
|
ITU APS Annex-A
|
switchback
|
Redundancy activities. The existing command switchback is modified to switch back to the primary module from the redundant module for the SRM-E.
|
SRM-E
|
xcnfalm
|
Managing alarms.The existing command xcnfalm is modified to configure alarms for a line on the new card. The xcnfalm command allows only DS3 and E3 alarm thresholds to be configured.
|
SRM-E
|
xcnfcon
|
Two new values have been introduced for cesCas type to configure a channel with the multiframe option enabled. The values are ds1SfCasMF and ds1EsfCasMF.
The channels on a particular line can be either all MF (SF MF or ESF SF) or all non-mf (SF or ESF). The first connection type added on a particular line (mf/non-mf) decides the sync mode. The second connection must have the same cesCas type, and so on.
|
FRSM-HS2/B
|
Node Related
A maximum of one BERT test can be performed per bay at any point in time. The command addln should be issued before executing the addapsln command.
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in to the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration publication on the documentation CD.
Step 1 Use ftp to port the Axis 5 common boot image for the service module to a workstation.
Step 2 Plug in the card into the MGX 8220 shelf.
Step 3 Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
tftp <ip address of the MGX 8220 shelf >
put <boot filename> AXIS_SM_1_<slot#>.BOOT
Insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Step 1 Log into the shelf.
Step 2 Verify that the two checksums are the same.
If not, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Caution If the checksums are not the same when you remove the service module, then the service module will not boot when it is plugged in and the service module will have to be returned using the Cisco Returned Material Authorization process.
Whenever an MGX 8850 is added as a feeder to a BPX 8600, SWSW automatically programs a channel with a VPI.VCI of 3.8 for use as the IP Relay channel. IP Relay is used to send IP data between nodes via the network handler, allowing every node in the domain to be directly addressable via IP addressing and CWM workstations to communicate with every node (especially feeders) using TELNET, SNMP and CWM protocols. If the user tries to add a channel with a VPI.VCI of 3.8, the BPX 8600 does not prevent the user channel from being added, but the MGX 8850 rejects it. To delete the added channel on the BPX 8600, and to get IP relay working you need to reset the BXM card.
In addition to clearing the entire configuration, clrallcnf clears the network IP addresses. IP addresses and netmasks stay the same (dspifip). However, it's recommended by engineering to reconfigure them using the cnfifip command. Network IP is gone (dspnwip), and must be re-configured using the cnfifip command. Refer to the entry on cnfifip in the Cisco MGX 8850 Command Reference publication on the documentation CD for syntax.
•The copychan command does not work.
A minimum of two and up to four IP addresses are needed to be configured for MGX 8850 (one or more of the following: Ethernet, ATM, SLIP) and the boot IP address. The user should use bootChange to set up IP gateway when the PXM card is just installed. The IP default gateway should be on the same subnet as the PXM board. Use the bootChange command to set correct IP address, netmask, and default gateway.
Do not install a Y-cable on the UIA CP port for PXMs. If you do, both serial ports will be enabled and you will not be able to communicate with the shelf through the console ports. If after switchcc the standby PXM loses the down-level port, it is most likely due to a downlevel Beta version of UIA back card that was shipped during field-trial only. Upgrading the UIA back card to the latest version should fix this problem.
To configure the external clock source, use the interface label 7.35. Do not use 0.33 or 7.33.
There are also routeShow/routeAdd/routeDelete commands for modifying routing tables.
You must reboot your PXM after each modification with "bootChange" for it to take effect.
- Only enter the ethernet IP address, netmask and default gateway.
- Type "." to erase incorrect entries.
tigers.1.7.PXM.a > bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
host name :C <-- Please put "C".
inet on ethernet (e) :172.29.37.40:ffffff00 <-- Ethernet IP Addr/Netmask
gateway inet (g) :172.29.37.1 <-- Default Gateway
ftp password (pw) (blank = use rsh):
- Type in reboot, after this the command "ping" will work:
tigers.1.7.PXM.a > ping 171.71.54.53 1
Service module upgrades error handling is not provided. If the user skips any of the steps during upgrade or if a power failure happens in the middle of the upgrade, results will be unpredictable. See the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.
The MGX 8850 supports 15 simultaneous Telnet sessions and 10 TFTP sessions.
You must use the following Y-cables for FRSM-HS2 and FRSM-CT3 redundancy as specified in the Product Orderability Matrix (Straight Cable: 72-0710-01, Crossover Cable: 72-1265-01, Straight Y-cable: FRSM-HS2: CAB-SCSI2-Y, FRSM-CT3: CAB-T3E3-Y). Other cables are not supported.
Y-cable redundancy for FRSM-HS2, FRSM-2CT3, FRSM-2T3, FRSM-2E3 is supported only for adjacent slots.
There is no need to issue the syncdisk and shutdisk commands before removing the PXMs. The system quiesces the disk by detecting the removal of the PXM board and flushes the write buffers to the disk and puts the PXM in sleep mode. This disables any further hard disk access since it locks the actuator. When the card is reinserted the PXM automatically comes out of sleep mode.
Caution Cooling and Power limitations: Customer should be aware of the need for extra power supplies and fans beyond certain limitations. A single fan tray will support all configurations that draw between 1200 and 1400 watts. For power requirements, the MGX 8850 requires a minimum of one power supply per line cord to support the power requirement for five cards.
|
0-5 Cards
|
6-10 Cards
|
11 and Above
|
Single Line Cord (N+1):
|
2
|
3
|
4
|
Dual Line Cord (2N):
|
2
|
4
|
6
|
This is based on an estimated worst-case power requirement of 190W plus margin per card slot.
Connection Management Related
The name of the node cannot be changed if there are PVCs. The node name must be changed from the default value before adding connections, since it cannot be changed later. Use the cnfname command to change the node name.
Only one feeder trunk can be configured. No BNI trunk to MGX 8850 as a feeder is supported.
The slave end of a connection must be added first.
The slave end cannot be deleted and re-added back by itself. If you delete the slave end, the entire connection must be completely torn down and re-added back. If the slave end of the connection is deleted and re-added back by itself, then unpredictable results will happen.
For user connections, VCI 3 and VCI 4 on every VPI are reserved for VPC OAMs.
The actual number of feeder connections you can provision on the PXM is always two less than you have configured. The dsprscprtns command shows max connections as 32767, but you can only use 32767 - 2 = 32765. One connection is used for LMI and another one for IP relay.
There is no error handling detection while provisioning through the CLI. Invalid endpoints and unsupported connection types (such as connections between FRSM-CESM ports or connections between structured and unstructured connections) are permitted using the CLI. The user should not configure these connections.
The sum of CIR of all channels of a port can be greater than port speed as long as CAC is disabled. However, it is not acceptable for one channel's CIR to be greater then port speed even if CAC is disabled. Two channels added up can exceed port speed. This means you cannot oversubscribe a port if only one channel is configured.
When trying to add a port on DS0 slot 32 of a CESM-8E1 line using an SNMP set or the CiscoView Equipment Manager, the SNMP agent in CESM will time out, without adding the port. The SNMP libraries treat the 32 bit DS0 slotmap (cesPortDs0ConfigBitMap) as an integer. The value for the last DS0 is treated as the sign value. This causes a corruption in the packet coming to the agent. As the agent does not receive a complete SNMP packet, it does not respond and times out. Use the command line interface to add a port on DS0 slot 32 of a CESM-8E1 line.
The cnfport command does not allow VPI ranges to be reduced. The cnfport command only allows the VPI range to expand. The correct sequence is to delete all connections on the partitions, delete the partitions, delete the port, and add the port with new VPI range.
On an FRSM-2CT3, one can add 128 ports on a group of 14 T1 lines as indicated below.
• lines 1 to 14: 128 ports (A)
• lines 15 to 28: 128 ports (B)
• lines 29 to 42: 128 ports (C)
• lines 43 to 56: 128 ports (D)
So, to add 256 ports on one T3: add 128 ports on the first 14 T1 lines and the remaining 128 on the next 14 T1 lines.
Note that (A) and (D) are connected to first FREEDM and (B) and (C) are connected to the second FREEDM. Each FREEDM supports only 128 ports. If 128 ports are added on one T3 as in (A), then there cannot be any more ports as in (D). The 129th port should be on lines 15 to 42 (as in B or C).
If the user adds a connection between an RPM and a PXM and then deletes the connection, the RPM shows no connection but the PXM still has the connection. The MGX was designed and implemented in such a way that only the connections that have the master end show up on PXM (by dspcons command). Consider these three connections:
•c1: has only slave end
•c2: has only master end
•c3: has both master and slave end
When using the dspcons command, c2 and c3 will be displayed, not c1. The connection will not show up once the master end (PXM) is deleted. Recommendation: When adding a connection, if one end of the connection is PXM, always configure the PXM side to be the slave. Thus when deleting the RPM side, which is the master, the connection will not show up on the PXM. However, keep in mind that the slave end (PXM) still exists. This also provides a side benefit. When a connection exists with only the slave side, no bandwidth is occupied. The bandwidth is reserved only if the master end exists (with or without the slave).
The MGX-FRSM-HS1/B is capable of supporting a total throughput (card-level) of 16 Mbps. However, it is possible to configure four lines each supporting up to 8 Mbps, thus oversubscribing the card. This has been raised in bug #CSCdm71476 and a restriction/warning will be added in a future release.
Addlnloop on an FRSM-HS1/B line works only when there is a (valid) cable plugged in to the back card on that line. This is a hardware limitation on the back card and has been mentioned in the Release Notes in bug# CSCdm44993.
RPM Related
The RPM-PR and MGX-RPM-128M/B operate under the following IOS and Release 1 software.
MGX SW version
|
1.1.32
|
1.1.34
|
1.1.40
|
1.2.00
|
"Bundled" IOS SW version
|
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.2(2)T2
|
12.2(4)T
|
12.2(4)T1
|
CWM
|
10.4.01
|
10.4.01 Patch 1
|
10.5
|
10.5.10
|
With MGX Release 1.1.32, two Route Processor Modules (RPMs) are supported; the MGX-RPM-128M/B and the RPM-PR.
The MGX-RPM-128M/B is a NPE-150 based router card capable of sustaining 150,000 pps. The RPM-PR is an NPE-400 based router capable of sustaining over 350,000 pps. The RPM-PR will only operate with IOS 12.1(5.3)T_XT or later. For the following section "RPM" will refer to both the MGX-RPM-128M/B and the RPM-PR, (unless specifically called out) even though some software versions and limitations are not applicable to the RPM-PR because it doesn't support IOS versions before 12.1(5.3)T_XT.
With MGX-RPM-128M/B versions earlier than 12.O.7T1, some limitations in Inter-Process Communication when the MGX-RPM-128M/B is at high loads can cause the PXM to declare that the MGX-RPM-128M/B has Failed. To avoid this with MGX-RPM-128M/B, software releases earlier than 12.0.7T1, throughput is limited to 62,000 pps, and it is recommended that MPLS configurations are limited to 100 interfaces. With RPM software releases from 12.0.7T1, those limitations are removed. In a separate limitation, the number of directly connected OSPF networks supported by an RPM is currently limited to 27. This means that any or all of the subinterfaces supported by the RPM can run OSPF, but the number of distinct OSPF networks supported is limited to 27. (A work around is available and is discussed below.) The limit of 27 arises because of the overheads of supporting separate link-state databases for separate networks.
In an application where the RPM is a Provider Edge Router in an MPLS Virtual Private Network service, a much better solution in any case is to use a distance-vector routing protocol between the customer routers and the RPM. A distance-vector routing protocol provides exactly the information required for this application: reachability information, and not link-state information. The distance-vector routing protocols supported by the RPM are BGP, RIP v1 and RIP v2, as well as static routing. With RPM software releases from 12.0.7T1, distance-vector routing protocols can be used with as many different networks as subinterfaces.
Note that if the RPM is acting as a Provider Edge Router in an MPLS Virtual Private Network service, and even if OSPF is running in a customer network, it is not necessary to run OSPF between the customer router and the RPM. If the customer edge devices run Cisco IOS, they can redistribute OSPF routing information into RIP using the IOS commands, redistribute RIP in the OSPF configuration, and redistribute OSPF in the RIP configuration. Similar configurations are possible for BGP. (For more information on re advertisement, see the "Configuring IP Routing Protocol-Independent Features" chapter in the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1). Redistribution is not unique to Cisco CPE, and other vendors' equipment also supports redistribution.
RPM Front Card Resets on 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).
MGX-RPM-128M/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.2.00
The following is the list of problems fixed in the service module firmware and the Release 1.2.00 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCdr61328
|
Symptom:
The delete bit is not set in the Async Lmi Packet when a connection is deleted.
Conditions:
The delete bit in the Annex-A/Annex-D has been masked hence the delete bit is not set in the Async Lmi Packet when a connection is deleted.
Workaround:
None.
Further Explanation: Scenario: 1. Configure a port with PVC Asynchronous Status Report enable. 2. Add a PVC. 3. Delete the PVC.
Problem: 1. The "Delete bit" in the PVC IE is not turned on.
|
CSCdr88604
|
Symptom:
The alarm on SRM lines are not getting updated. Even when the line is deleted the alarms exist.
Conditions:
Workaround:
Do clralm on the deleted line which has the alarms.
|
CSCds01403
|
Symptom:
There is a mismathch in usage systax in dspportq.
Conditions:
When execute the dspportq without parameters and with non-numeric characters.
Workaround:
None.
|
CSCds02030
|
Symptom:
cnfcon and xcnfcon allows mcr value = 0, which is different from given syntax.
Condition: When execute cnfcon and xcnfcon with mcr = 0.
Workaround:
None.
|
CSCds05040
|
Symptom:
The major alarm LED on the active and the standby PXM on MGX8850 are on, while the CLI commands do not show any indication of alarm.
Conditions:
If the SRM backcard in the redundant core card set is removed and reinserted, the alarms on the shelf will be clear, but the MAJ alarm LED alone will be left turned on.
Workaround:
Perform switchcc to clear the LED.
|
CSCds07944
|
Symptom:
clralmcnt -ds3 does not clear the counters.
Conditions:
Workaround:
Use clralms -ds3
Further Problem Description:
|
CSCds10270
|
Symptom:
When a OC-12 feeder trunk is configured as 1+1 unidirectional mode, the PXM-622 OC-12 line on slot 7.1 of peartx40 MGX node did not have the option in specifying whether the "working" or "protection" line would be applied upon an external request such as "Manaul Switch" and "Forced Switch". This will prevent the capability to allow a user to change a request from "MS: W->P" to "FS: W->P" directly. The options allowed under the "switchapsln" command are listed as below:
Conditions:
With APS configured and trying to do switchapsln.
Workaround:
None
Further Problem Description:
None
|
CSCds21131
|
Symptom:
The LineOOFCriteria on a PXM card with DS3 daughter card shows "fBitsOf16" when configured for "fBits3Of16".
Conditions:
Applies to PXM with T3 trunk module.
Workaround:
None.
|
CSCds26477
|
Symptom:
Displays wrong Front card description for CESM T3/E3 cards.
Conditions:
For CESM T3/E3 card, Cisco View displays wrong description for front card description field.
Workaround:
No workaround.
|
CSCds27547
|
Symptom:
The BERT test were running on two Service modules: one in the upper bay of the Popeye node and one in the lower bay of the popeye node but dspbert was displaying only one of them. Once the BERT was deleted on that slot, then only dspbert showed that the BERT is running on the other slot.
Conditions:
Workaround:
Use dspbert <second slot#> to verify whether the BERT is running on the second slot or not.
|
CSCds29448
|
Symptom:
The line status for disabled lines in line table shows inconsistent in database.
Conditions:
This happens when repeated queries are being done on the switch for line alarm_state from the CWM workstation.
Workaround:
Under investigation.
|
CSCds34186
|
Symptom:
LMI is not functioning as per requirement for FUNI.
Also, attempting to configure LMI for a FrFowarding port is not allowed but the error message is somewhat confusing.
Conditions:
Whenever LMI is configured for FUNI.
Workaround:
Under Investigation.
|
CSCds37553
|
Symptom :
Port shows ILMI failure though there is no failure.
Condition :
Happens on 5.x firmware with version 5.0.12
Workaround :
Card reset or softswitch clears this problem.
|
CSCds38145
|
Symptom:
Lmi debugging facilities to be ported from AXIS.
Conditions:
Not applicable
Workaround:
Not applicable
Further Problem Description:
The LMI debugging facilities provided in the FRSM_HS1 of AXIS is to be ported to POPEYE branch.
|
CSCds38166
|
Symptom:
On PXM with Stratum-3 backcard (UI-S3), the external clock src, configured as E1, seems to revert to T1 after a switchcc. The dspclkinfo command output says it is a T1 clock. ***APPLIES to UI-S3 backcards _and_ the external clock source of E1 only.
Conditions:
No service impact. Display is wrong. The clock source is still external and E1. However, the workaround MUST be implemented to after every switchcc to make sure tehre is no further service impact after subsequent switchcc's.
Workaround:
After every switchcc, execute the command: cnfextclk 2 This will update the necessary fields, correct the dspclkinfo output, and prepare the shelf for subsequent swithcc operations.
Further Problem Description:
1) The bug only effects Stratum-3 backcards. 1) The bug is not service effecting (display issue) 2) a workaround exists 3) there are indirect indicators that show the actual state of the clock source.
Here is a brief description: Synopsis: CSCds38166 -- External clock cnf of E1 lost on switchcc In reality, the logic that reads the HW registers and displays the output of the dspclkinfo command is flawed. Root cause: Actually, what happens is, the field that determines the value of the clock input jack is used to determine whether the source is an E1 or a T1 clock. This works fine for Stratum-4 backcards, but for Stratum-3 backcards, the same input is used for T1 and E1, so the logic defaults the display to t1. The clock source is still external clock, and no service is impacted.
Impact:
After the first switchcc, there is no service impact. However, there is a danger for a subsequent switchback: Since once the field is wrongly updated to "t1", on switchcc, the PXM that takes over will try to find a T1 clock input, and will fail, switching to internal clock.
Workaround: after every switchcc, login to the shelf and do a:
"cnfextclk 2". This will cause all fields to get updated correctly, and will enable a subsequent switchcc to not lose external E1 clock. This command will also straigthen out the display of the command dspclkinfo.
|
CSCds48471
|
Symptom :
When an IMA port and ATM port are added in a AUSM card and ILMI is enabled on both, after ILMI failure clears, dspcd still shows Minor alarm with PORT ILMI fail.
Condition :
Happens on 5.0.13 AUSM firmware.
Workaround :
Execute find_out_port_fail_for_shelf_alarm under shellConn in AUSM. This will clear the problem.
|
CSCds58040
|
Symptom:
Cannot login into 8250 using a newly created userid.
Conditions:
In 8250 releases 1.1.30 to 1.1.32, new user account is created with adduser CLI and subsequent xcnfuser CLI.
Workaround:
Create the new user account with adduser CLI. Then before the xcnfuser CLI is used for the newly created account, login using the new account from another terminal and logout.
|
CSCds67365
|
Symptom
These bug is opened to resolve the warnings reported by a code coverage tool PREfix. The warnings reported include "uninitalized variables" etc. Hence the symptom for this bug is unknown.
Conditions
Normal working conditions
Workaround
None.
|
CSCds77223
|
Symptom:
Changing the ingressq to the minimum value of 4510 on a FRSM card causes all traffic to be discarded. This occurred on 1.1.23 and 1.1.31.
Conditions:
Change of ingressq to the minimum value of 4510
Workaround:
Changing the minimum ingressq to 4511 fixes the problem.
|
CSCds81198
|
Symptom:
dspcons display on FRSMHS1B is not alligned starting from channel feild
Conditions:
addcon on FRSMHS1B on POP1/1.1.32 then run dspcons
Workaround:
None.
|
CSCds87189
|
Symptom
RcvLOS count toggles between 0 and 252.
Conditions
When executing addds1loop/delds1loop.
Workaround
None.
Further Problem Description
None.
|
CSCds90673
|
Symptom:
The card is in Bulk Mode Now as thr SRM Line is in alarm the line/port/connection are also in alarm. Now if we reset the card, the line/connection are still in alarm as expected but the port i
Conditions:
When the card is put in Bulk Mode & then a reset card is done.
Workaround:
Problem under investigation.
|
CSCds91080
|
Symptoms;
The command addport with wrong port type causes Data Bus Error
Condition:
The command addport on frsmhs1b using wrong port type (other value than 1 or 2 or 3).
Workaround:
Use only valid port type values (1, 2 & 3)
|
CSCdt05984
|
Symptom:
The command xcnfchan does not dispay the sertp options correctly
Conditions:
xcnfchan command on FRSM3T3
Workaround:
None.
|
CSCdt18908
|
Symptom:
The command dspcons on FRSM-2T3 increments ChanNumNextAvailable field and skips 1 channel when adding next connection.
Conditions:
Issue addcon command and monitor ChanNextNumAvailable field.
Workaround:
None.
|
CSCdt19174
|
Symptom:
dspcons increments ChanNextNumavailable field and hence addcon skips next channel number by one.
Conditions:
When adding connections and using dspcons.
Workaround:
None.
|
CSCdt19187
|
Symptom:
dspcons or dspchans increments the LocalVpIdNextAvailable by 2.
Conditions:
When performing dspcons/dspchans.
Workaround:
None. Not Service Impacting.
|
CSCdt28566
|
Symptom:
Frames are getting dropped due to port queue overflow without any frames being tagged on the egress direction. dspchanct for the channel would show increasing values for FramesDiscarded count and FramesByteDiscarded in the Tx direction. dspportcnt for the port would show increasing values for XmtFramesDiscXceedQDepth and XmtBytesDiscXceedQDepth in Tx direction.
Conditions:
This occurs when the Queue threshold for the port is configured very low.
Workaround:
use cnfegrq cli to configure the queue threshold accordingly. Note that in case of Ratio Based Servicing, the queue number of high priority is 1 and low priority is 2. In case of WFQ use the class of service index to refer to the queue number.
Verify that the values are set properly using the shellConn command "eseQueInfoShow" This command takes two parameters, the port number and the queue number.
After setting the threshold to proper values, reset the card to get the changes into effect.
Further Problem Description:
The cnfegrq doesnot 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 datastructure and display proper queue numbers to use during different servicing algorithms.
|
CSCdt40267
|
Symptom:
CAC override is not sent to the CWM in the config upload file
Condition:
This parameter is not included in the config upload files.
Workaround:
No work around till the CAC override parameter is added to the config upload file. This has been added to the config upload file to fix this bug.
|
CSCdt43225
|
Symptom:
Some channels are stuck in alarm. dspchancnt shows that the channels are receiving OAM AIS, but dspsarcnt does not show that OAM AIS is received. The far end is not sending OAM AIS either.
Conditions:
This problem happened when the CPE equipment was connected to the port.
Workaround:
Fail the port and recover it(by changing the port signalling).
|
CSCdt45615
|
Symptom:
Misleading log message when back card is missing.
Conditions:
When Backcard is missing.
Workaround:
None.
|
CSCdt76729
|
Symptom:
Remote Loopback operation is not blocked by CiscoView on a AUSM 8T1 line. There will be no traffic continuity on the line after a remote loopback is added and removed.Conditions:
Add a remote loopback on AUSM8T1 and remove it. Data continuity is lost.
Workaround:
Workaround is after adding and removing the remote loopback on the AUSM line one has to add and remove a local loop on that line again through Ciscoview
|
CSCdt87411
|
Symptom:
With an MGX configured and connected to an External clock source it has been observed that on a switchcc the newly active PXM fails the externl clock and switches to internal for up to 10 seconds.
This is a problem as it causes errors on 64K unrestricted data calls and could also cause problems on high speed modem calls.
Conditions:
External clock configured on the node.
Workaround:
None.
|
CSCdt90660
|
Symptom:
The FRSM-VHS card goes to failed state and after Redundant card takes over all lines go into alarm.
Conditions:
Trunk errors on the BPX trunk through the failed card has connections routed through.
Workaround:
Reset the the Failed VHS card.
|
CSCdu00363
|
Symptom:
Connections shows invalid PCR after deleting links from ima grp.
Conditions:
When you have connections configured under an ima group & then you try to delete few links from the existing ima group by executing CLI: dellnsfmaimgrp.
Workaround:
None.
|
CSCdu02695
|
Symptom:
When MGX is running on external clock and SM lines are set to local timing, we intermittantly see slips on attached device interface even though both the attached device and the MGX show they are both taking clock from the same external source.
Conditions:
This happens when external clock is the current clock for the node.
Workaround:
If the external clock is disconnected and reconnected from the Active PXM UI card, the clock slips then stop and all is OK.
|
CSCdu03185
|
Symptom:
Allowing more than expected CLP1 cells into the network by the policing function on VBR.2 (rt/nrt) connections on AUSM 8T1.
Condition:
This could potentially lead to network congestion.
Workaround:
Unknown.
|
CSCdu06781
|
Symptom:
Back-to-back forced/manual (W->P followed by P->W) switch was permitted when the latter external user request is initiated from the remote end.
Condition:
Check for remote request of equal priority is not in place.
Workaround:
None.
|
CSCdu12589
|
Symptom:
The value of the varbind 'sonetLineCurrentStatus' is not consistent in the sonet line traps: 50108 (line alarm trap) and 50109 (line no alarm trap)
Conditions:
When the sonet line on PXM goes in and out of alarm
Workaround:
None.
Further Problem Description:
Till now, CWM was just looking at the value of this varbind 'sonetLineCurrentStatus' to decide whether to put the lines into alarm or not irrespective of the trap no. So because of this inconsistent definitions, sometimes it use to put the connections in alarm even after receiving 50109. Now it has been agreed that they will make this decision based on the trap no rather than the varbind value. Once that is done, the impact of this issue will become less.
|
CSCdu14185
|
Symptom:
Unable to add RPM connection
Conditions:
Condition was caused by using CM and adding the ATM(RPM) to ATM(RPM) connection from mgx8250 to mgx8230 and the error was: Connection add request to PXM failed.
Workaround:
Using CM to add 3-segment connection: ATM(RPM) - ATM(RPM) .
|
CSCdu17049
|
Symptom:
On an MGX 8250 running version 1.1.25, if an addcon is done on an RPM and the remote end of the connection is on port 256 of a FRSM-2CT3, the command is rejected with the following message "Error:addcon:0:Connection add request to PXM failed". If an attempt is made to add a connection from the RPM to a port numbered 255 or lower, the connection is added. If an attempt is made to add a connection from another module (eg. AUSM) to port 256 on the FRSM, the connection is added. This problem is reproducible in version 1.1.32.
Conditions:
Connection is provisioned from RPM to FRSM-2CT3 with the port number on the FRSM as 256.
Workaround:
The current workaround is to use a port number less than 256 when adding connections between the FRSM-2CT3 and the RMP.
|
CSCdu17838
|
Symptom:
Line alarms clear after a card reset if lines are connected back to back on the same card.
Conditions:
Only when 2 lines on the same card are connected back to back.
Workaround:
Up the other side of the lines (and delete it).
|
CSCdu21136
|
Symptom:
Channels do not come up to the active state.
Conditions:
After a softswitch is done between slots 22, and 30, then a switchcc.
Workarounds:
Do a second switchcc, and the channels come up to the active state. Increase the value of gu32TimeoutValue to 500 in shellConn on the AUSM before doing a switchcc.
Further Problem Description:
The problem happens because of management buffer depletion causing the IMA active trap to get lost, so the PXM never gets the information that the port has become active. The problem has been fixed by increasing the value of the alarm integration timer to 5 secs. This is done by changing the value of gu32TimeoutValue in the code..this timer prevents the channels from going into alarm for the duration of the timer even after the port fails. This is also a fix for CSCdv90898, but for that problem it might be required to increase the above value in shellconn depending on the cpe device.
|
CSCdu24006
|
Symptom:
Non-Existing connections are displayed on AUSM cards
Condition: MGX:8250 AUSM: 10.0.22 PXM 1.1.33Ak
Workaround:
None.
|
CSCdu27251
|
Symptom:
CESM card sometimes gets stuck in the failed state if a resetcd is done on it. The CESM may also go in the failed state if a cc is done to the card or the addcon command is executed on it.
Conditions:
This happens if the PXM has a UI-S3 back card and a switchcc is done. The shelf needs to be running on Stratum 3 level internal oscillator for this problem to occur.
Workaround:
If the shelf is running on Stratum 3 level internal oscillator and there is a switchcc, re-execute the following command on the new active card:
cnfclklevel 3
Further Problem Description:
Please contact cisco TAC for a workaround referencing this bug id.
CESM shows up as failed on the PXM. A shellConn command scmConnShow will not show a connection built to the failed card, e.g.
-> scmConnSho scmConnShow 6
<SCM> Connection with standby PXM is up <SCM> Connection with SM 1 is up
<SCM> Connection with SM 2 is up <SCM> Connection with SM 5 is up <SCM>
Connection with SM 13 is up <SCM> Connection with SM 14 is up <SCM>
Connection with SM 17 is up <SCM> Connection with SM 18 is up <SCM>
Connection with SM 30 is up value = 1 = 0x1
Here we do not see the connection with SM 6 and this the card 6 (cesm) shows up as failed when you do a dspcds on the PXM.
|
CSCdu28072
|
Symptom:
The command dspcd shows channel failure eventhough connections doesnot exists on the card.
Conditions:
This happens if before deleting the last connection on a card, that channel had an alarm on it.
Workaround:
Delete the port and line on which that channel was present and re-add the port/line back.
|
CSCdu29422
|
Symptom:
Trap Manager doesn't get deleted from the standby
Condition:
XM Ver: 1.1.33Al Trap Managers are added, this gets updated on standby too. On Aging, they are deleted only on the Active Card and not on the Standby. (on switchcc, Trap Managers are seen as Enabled inspite on aging.)
Workaround:
Not Known.
|
CSCdu29788
|
Symptom:
Cannot configure line type on FRSM 2E3 other than G.751.
Conditions:
MGX:8250 PXM:1.1.33Al FRSM-2E3.
Workaround:
Under Investigation.
|
CSCdu34346
|
Condition:
Issue the 'addred <primary> <secondary> 2' command. The primary and secondary RPM cards should have different (number or type) of backcards.This condition also applies to the case when each card has one backcard each, both of the same type, but in different slots.
Result:
The following warning is to be expected----
addred:Prim and Sec LineModule type Mismatch. Command will proceed for the card type.
|
CSCdu37806
|
Symptom:
The command xcnfln -lpb 3 is not supported on FRSM-HS2
Conditions:
Always.
Workaround:
None.
|
CSCdu39150
|
Symptom:
The command dspchancnt 2000 gives an error message on FRSM-2CT3
Conditions:
MGX 8230/8250 FRSM-VHS card has channel number 2000 enabled.
Workaround:
None.
|
CSCdu42117
|
Symptom:
The dsplog has a message that says "Unable to config requested clock source because clock source 8 is unknown."
Conditions:
This message will be seen when the clock source or the node changes.
Workaround:
None.
|
CSCdu42490
|
Symptom:
After MGX1 Power On boot, dspclkinfo shows StratumLevel = none. If the PXM1 back card is UI-S3, StratumLevel should be 3 or if the back card is UI, it should be 4.
Condition:
MGX1 Power On boot.
Workaround:
After MGX1 Power On boot, program: cnfclklevel = 3 for UI-S3 back card cnfclklevel = 4 for UI back card.
|
CSCdu43261
|
Symptom:
AUSM does not display line alarm information correctly.
Conditions:
When the T1 interface is shut from the 3810.
Workaround:
None.
|
CSCdu43980
|
Symptom:
The Qdepth range is shown incorrectly on AUSM card.
Conditions:
MGX:8250 AUSM 8T1/E1.
Workaround:
Use valid values from 33 to 16000.
|
CSCdu45583
|
Symptom:
Slot #30 that was covering for Slot #28 rebooted.
Conditions:
After a switchcc on the PXM while secondary card is covering primary card. Need to have two IMA ports on this card connected with a cisco 3660 router.
Workaround:
Softswitch back to primary before switchcc.
Further Problem Description:
The problem only happens with IMA configuration.
|
CSCdu51929
|
Symptom:
After External Reference is lost, Stratum3 clock controller on UI-S3, PXM1 back card may not go into Holdover mode or Internal Free Run.
Condition:
Cable removed from CLK1 or external clock reference signal loss.
Workaround for Rls up to and including 1.1.34:
No need, if external reference is restored. Stratum3 clock controller will lock back to the external reference automatically.
If external reference is lost permanently, clock controller should be reprogrammed to be Stratum4 by executing CLI command cnfclklevel=4 and selecting INBAND reference from a feeder trunk.
|
CSCdu54264
|
Symptom:
The command switchapsln s x does not work.
Conditions:
APS configured.
Workaround:
None.
|
CSCdu54804
|
Symptom:
Wrong ChanConnPCR value displayed after xcnfcha.
Conditions:
Always.
Workaround:
None.
|
CSCdu55116
|
Symptom:
The command dspchstats will not work on a FRSM-VHSHS2 card. When executed a unknown command response is returned. The command is listed in the help menu.
Conditions:
Workaround:
None.
|
CSCdu55166
|
Symptom:
IMA lines removed from the IMA grp when slot #28 is covering for slot #30.
Conditions:
When a switchcc is performed.
Workaround:
Just restart the imagrp, and all lines come up as present.
|
CSCdu58229
|
Symptom:
APS switches working to protect on the BXM side but not on the PXM side.
Conditions:
BPX APS configured as Bidirectional, Nonrevertive and the remote node is Pop1 PXM with the same APS configuration. There is a following sequence of events: 1> Due to either a MANUAL switch or a FORCE switch, the protection line is the active line. 2> There is a fiber-cut/LOS on the receive side of protection line at the BPX end.
Workaround:
Perform APS lock on the PXM and do a APS clear.
|
CSCdu61609
|
Symptom:
CiscoView shows inconsistent status for lines in 1:1 FRSM-2T3 in MGX8250
Conditions:
1:1 red. between cards
Workaround:
None.
Further Problem Description:
When FRSM-VHS cards are configured for 1:1 Hotstandby redundancy, the standby card's database will be in sync with the primary card's database. If the lines on the Active card are enabled, then snmpget for the same lines on the standby card returns them as enabled. The line LED's on the standby card will show no colour, as the lines are not made ready to handle traffic since the card is in standby state.
|
CSCdu62613
|
Symptom:
On BXM, clearing request APS Force W->P switches the active line to Working.
Conditions:
APS 1+1, Bidirectional nonrevertive. BXM connected to PXM. In Sequence Both nodes start on Protect with no requests On PXM, Manual P->W On BXM, Force W->P On BXM, Clear requests
Workaround:
Clear any request on PXM before issuing a request on the BXM.
|
CSCdu63090
|
Symptom:
Input rate less than EIR but 'dspchancnt' shows frames discarded due to UPC.
Also, 'RcvFramesDiscUPC' and 'FramesDiscXceedDEThresh' did not sum to the total dicarded frames.
Condition:
Happened on FRSM-VHS cards when EIR > Input rate > PIR.
Workaround:
Unknown.
|
CSCdu63686
|
Symptom:
The portM32EgressQueThresh is not preset int the .CF file. This impacts CWM.
Conditions:
TFTP of .CF file.
Workaround:
None.
|
CSCdu66317
|
Symptom:
Trap 50609 was received with a invalid failure code.
Conditions:
Unknown.
Workaround:
None
Further Problem Description:
|
CSCdu66738
|
Symptom:
Trap 50041 coreCardsPeerMismatch received with invalid shelfSlotNum.
Conditions:
When there is core card mismatch.
Workaround:
None.
|
CSCdu67926
|
Symptom:
The traps 50231 and 50230 are received with incorrect varbind ids but the correct information for the varbind listLinksPresentInImaGrp, the varbind listLinksInImaGrp is sent instead.
Conditions:
These traps are always sent with the wrong varbinds, but the information contained does represent the correct varbind i.e even though the varbind listLinksInImaGrp is being sent it actually contains the 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 alongwith 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 alongwith the ports on it. Executing 'addds3loop <ds3>' clears the port alarms but not the ds1.
Ds1 and Ds3 Loop should be independent of each other . We are keeping addition/deletion of ds1 loop independent of the state of the ds3 loop.
|
CSCdu68068
|
Symptom:
CLI commands display the same info for ratio queue vs. weighted fair.
Condition:
On both the dspegrq, and the cnfegrq commands.
Workaround:
None.
|
CSCdu68073
|
Symptom:
The xcnfalmcnt command accepts any parameters and does not display any error messages.
Conditions:
When xcnfalmcnt command is executed with invalid parameters.
Workaround:
None.
|
CSCdu68402
|
Symptom:
Conditions:
Workaround:
Further Description: This is a bug opened to resolve all errors found by running the PREFIX utility on the MGXPXM12 baseline
|
CSCdu72190
|
Symptom:
Active PXM reset due to 'Software Error Reset'. Standby PXM took over. There is no service impact.
Conditions:
When CiscoView is running and SRM T3 lines are enabled. The time it takes for the PXM to reset depends on the number of instances of CiscoView running. The PXM reset happens approximately every 4 hours when running more than 80 instances of CiscoView.
Workaround:
None.
|
CSCdu74747
|
Symptom :
Sometimes, while adding a new connection, ports are not showing up in the selection window properly in spite of their being present in the database. For example if the database has 4 ports for a card and shelf, it shows up only two of them or it does not show any.
Conditions :
It is intermittent and highly random.
Workaround:
Hit Cancel button so that the new connection window disappears. And restart the configure new connection window from connection manager gui. On the MGX side the problem is not seen if a physical(metallic) loopback is added instead of the soft loopback (through addlnloop).
|
CSCdu75928
|
Symptom:
PXM E1 ext clock sync not working without the Daughter card.
Conditions:
In the absence of the Daughter card or Back card, the External E1 clock will not sync and the clock status update would fail.
Workaround:
None.
|
CSCdu76964
|
Symptom:
When the CESM8T1E1 is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.
Conditions:
Occurs when the SM is in standby mode.
Workaround:
None.
|
CSCdu76974
|
Symptom:
When the SM is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.
Conditions:
Occurs when the SM is in standby mode.
Workaround:
None.
|
CSCdu76975
|
Symptom:
When the SM is in standby mode, it logs messages "Invalid message received from ACRED 3" in the log file.
Conditions:
Occurs when the SM is in standby mode.
Workaround:
None.
|
CSCdu77367
|
Symptom:
Conditions:
Workaround:
Before using the connections, it is advised to do node resync with the feeder nodes first. But if the connections are bouncing, this manual node resync may not help either.
|
CSCdu77367
|
Symptom:
Conditions:
Workaround:
Before using the connections, it is advised to do node resync with the feeder nodes first. But if the connections are bouncing, this manual node resync may not help either.
|
CSCdu79008
|
Symptom:
T1 alarm counters are missing.
Conditions:
FRSM-8T1E1.
Workaround:
None.
|
CSCdu83011
|
Symptom:
Misleading message when trying to do softswitch. a warning message of 'possible red table corruption' might lead to confusion.
Conditions:
When redundancy card is cover card A and trying to softswitch from card B to redundant card.
Workaround:
None. No actual impact.
|
CSCdu84628
|
Symptom:
In 1+1 bidirectional mode, local manual switch preempts remote manual switch request.
Conditions:
Workaround:
None.
|
CSCdu84643
|
Symptom:
In 1+1 uni/bidirectional APS, forced switch of p->w preempts forced switch of w->p
Conditions:
Workaround:
None.
|
CSCdu85051
|
Symptom:
In 1+1 bidirectional APS, lockout of protection not blocked by remote lockout of protection.
Conditions:
Workaround:
None.
|
CSCdu85063
|
Symptom:
In 1+1 uni/bidirectional APS, manual switch of p->w preempts manual switch of w->p.
Conditions:
Workaround:
None.
|
CSCdu86599
|
Symptom:On a 8 port CESM (AX-CESM-8T1) for the 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.
|
CSCdu88301
|
Symptom:
On an FRSM-HS1/B card, when traffic in excess of CIR is pumped from the network side, it causes Egress buffer overflow, which in turn causes the card to reset. Egress data buffer overflow can be checked by using the shellConn command SarShow on the FRSM-HS1/B.
Conditions:
This happens only on the FRSM-HS1/B version 10.0.22 .
Workaround:
An upgrade of the FRSM-HS1/B firmware to 10.0.23.
|
CSCdu88914
|
Symptom:
Not able to add channel with a error 'no more lcn available'.
Conditions:
Corruption in resource partition type
Workaround:
Use shell command to force update from service module to PXM.
|
CSCdv02276
|
Symptom:
Primary card in failed state after softswitch
Conditions:
Setup: PXM is running 1.1.34 2 AUSM's in 1:N Redundancy & running 10.0.11 version Now we upgrade the AUSM to 10.0.22 by doing a softswitch twice.
Problem: When doing the softswitch from secondary to primary when we do dspred we can see that the primary gets stuck in failed state.
Workaround:
Reset the secondary card before the first softswitch.
|
CSCdv02328
|
Symptom dspchans, dspifs show empty table if an abort is done in between upgrade
Condition:
Perform an install of 1.1.30 newrev 1.1.30 abort 1.1.30 At this point we lose ifs and chans
Workaround:
Here is the workaround for this problem, this should be applied only if an abort is required after the newrev stage during the upgrade. Before executing the abort command execute the following commands:
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)
|
CSCdv03072
|
Symptom: dspclkinfo
****** Clock HW registers ******** SEL_T1 = t1 SEL100 = ON SEL120
= ON SEL75 = ON NOEXTCLK = OFF
priMuxClockSource = INBAND_CLK1 prevPriMuxClockSource = INBAND_CLK1
primaryInbandClockSourceLineNum = 1 secMuxClockSource = INTERNAL_OSC
prevSecMuxClockSource = none secondaryInbandClockSourceLineNumber = 1
currentClockSetReq = primary currentClockHwStat = primary StratumLevel =
STRATUM4 PreviousClockHwStat = primary extClockPresent = Yes
extClkConnectorType = RJ45 extClkSrcImpedance = 100 Ohms Internal Clock
Status=255, Primary Clock Status=0
Secondary Clock Status=0, Last inband Clock State=0 last Inband Clock
state= 0, Last External Clock Present = 2
h1a.1.7.PXM.a > dspclksrc Interface Clock Type Clock Source
--------- ---------- ------------ 7.1 PRI
INTERFACE
h1a.1.7.PXM.a > cnfclklevel 3
h1a.1.7.PXM.a > dspclkinfo
****** Clock HW registers ******** SEL_T1 = t1 SEL100 = ON SEL120
= ON SEL75 = ON NOEXTCLK = OFF
priMuxClockSource = INBAND_CLK1 prevPriMuxClockSource = INBAND_CLK1
primaryInbandClockSourceLineNum = 1 secMuxClockSource = INTERNAL_OSC
prevSecMuxClockSource = none secondaryInbandClockSourceLineNumber = 1
currentClockSetReq = primary currentClockHwStat = primary StratumLevel =
STRATUM4 PreviousClockHwStat = primary extClockPresent = Yes
extClkConnectorType = RJ45 extClkSrcImpedance = 100 Ohms Internal Clock
Status=255, Primary Clock Status=0
Secondary Clock Status=0, Last inband Clock State=0 last Inband Clock
state= 0, Last External Clock Present = 2 :wq
Conditions:
Workaround:
|
CSCdv04213
|
Symptom:
1. Both primary and secondary cards in active state.
2. Secondary card locked. Unable to cc to the card.
3. Line on CESM T3 generates alarms.
Conditions:
To recreate the problem:'
1. softswitch' from primary(active) to secondary(stdby)
2. Then, reset active (secondary).
Workaround:
Unknown.
|
CSCdv08621
|
Symptom:
IP connectivity to the MGX1 node stops working after sometime.
Conditions:
IP connectivity is via a PVC configured between an UNI port and 7.34 on the PXM.
Workaround:
Delete the connection and readd it.
|
CSCdv09537
|
Symptom:
R_AM on protection line
Condition: Create LOS on protection, clear it and then create LOS on working.
Workaround:
|
CSCdv13383
|
Symptom:
Protection line status shows OK while remote SF condition on protection line exists.
Condition: 1+1 bidirectional APS configured.
Workaround:
None.
|
CSCdv13391
|
Symptom:
Late local equal priority request is selected in generating TxK1 after remote equal priority request is being acknowledged by PXM.
Condition: 1+1 bidirectional APS configured.
Workaround:
None.
|
CSCdv13400
|
Symptom:
PXM selects protection line and shows CH_MIS even though there is SF condition on remote BPX.
Condition: 1+1 bidirectional APS configured.
Workaround:
None.
|
CSCdv15625
|
Symptom:
When we do addlnloop on the srme card the alarms are still there. Basically the command does not work.
Conditions:
*)add line on srme oc3 card, addlnlloop on the srme line *)add a line in one of the SM's say FRSM on slot 1 line 1 *) addlink between slot1 line 1 to srme line. we can see that the line is still in alarm actually it should not be in alarm
Workaround:
The problem is because of hardware limitation. Supermapper chip has a version 2.0 which does not support the addlnloop. The newer version ie 2.1 or above supports addlnloop command. If we upgrade the supermapper to newer version then we should not see this problem.
|
CSCdv25524
|
Symptom:
The SNMP agent receives values 15, 16 and 17 for funtion module state which are not defined in the MIB.
Conditions:
When the card goes to CardInit state while booting up, the SRM card fails.
Workaround:
None.
Further Problem Description:
After the fix, state representing 15 and 16 have been removed. 17 has been defined as cardinit. That way when the old PXM image sends 17, the new SNMP agent will understand it properly.
|
CSCdv26309
|
Symptom:
Connection configured on FRSM 8E1 on an MGX8250 unabled to be deleted due to error "Port does not exist". Port is well configured and has other connections already configured and passing traffic. Also further connections cannot be added to he logical port 248 as same response is returned. Connections successfully added and deleted on other logical ports of the same card without problem/errs.
Conditions:
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 paralell sessions and run extended ping on each of the session.
Workaround:
Run extended pings from telnet sessions instead of cc to the card
|
|
CSCdv29944
Symptom:
Link addition on standby card successful. Condition: Add redundandant back card and then add link on this. Workaround : None
|
CSCdv31953
|
Symptom:
Unable to collect all stat types from CESM
Conditions:
Customer enabled all stat types on CESM. Connection Stats for CESM(CE Connection)
Object SubObjectId Statid Stat Description(as
shown in GUI)
0 10 16 Seconds In Service 0
10 58 AAL1 Sequence Mismatch 0
10 60 Receive Bytes Discarded 0
10 62 Rx Buffer Underflows 0
10 63 Rx Buffer Overflows 0
10 64 HCS Correctable Error 0
10 65 Loss of Pointer 0 10
66 Loss of Cell Delineation 0 10
69 Tx Bytes Discarded-Q-Overflow 0 10
70 Tx Cells Inserted-Q-Underflow 0 10
71 Total Cells Tx to Line 0 10
72 Total Cells Rx to Line
But only be able to get stats on AAL1 Sequence Mismatch HCS Correctable
Error Loss of Cell Delineation Total Cells Tx to Line Total Cells Rx to
Line
Workaround:
Under Investigation.
Further Problem Description:
Under Investigation.
|
CSCdv33089
|
Symptom:
Link/Line configuration is not deleted on srme after clrsrmcnf.
Condition:
Configure link.
Workaround:
None.
|
CSCdv35890
|
Symptom:
SRM-E stat files are bad intermittently.
Condition:
The node is synced up and used integrated SCM for collecting; only SRM-E Sonet line stats are enabled.
Workaround:
Not known.
|
CSCdv37960
|
Symptom:
PXM locks onto a bad clock added as a primary clock.
Conditions:
When PXM-UI-S3 back-card is used and clock level is Stratum 3.
Workaround:
Use the internal oscillator of the UI-S3 back card.
|
CSCdv39324
|
Symptom:
When FRSM 8e1-t1 with 10.0.20 have been provisioned or added without specifying a channel service type the default is blank. IF the card is upgraded to 10.0.22 the channels are automatically put into CBR queue and if new channels are provisioned the default service type is CBR. This causes problems with enabling foresight on these connections.
Conditions:
If connections have been added on the FRSM with a default chanservtype. And the card is then upgraded . This default is changed to CBR rather than nul . This causes problems with enabling foresight as it believes its a none ABR service. Code affected is when upgrading MGX8250 FRSM code from 10.0.20 to 10.0.22.
Workaround:
None, unless chanservtype has already been selected other than default to ABR servicetype.
|
CSCdv39679
|
Symptom:
PXM doesnot try to lock onto the secondary clock.
Conditions:
When PXM-UI-S3 back-card is used and clock level is Stratum 3 and primary clock has failed for some reason.
Workaround:
Use the primary clock or the internal oscillator of the UI-S3 back card.
|
CSCdv43539
|
Symptom:
Card not in alarm when line is.
Conditions:
One or more lines on V.35 interface are in major alarm.
Workaround:
Issue IntegrateCardAlarm(2,256,37) from shellConn.
|
CSCdv45481
|
Symptom:
Occurs when dsplns, dspalm, dspcd is used.
Conditions:
1. When the line moves from major alarm to minor alarm, dspalm indicates the line in the appropirate alarm, but dspcd will still be at major alarm and does not get updated to minor alarm. Vice versa is also true.
2. When delds3loop is executed on a line which does not have a loop configured, card alarm is cleared if the alarm was because of this line and even though the line is still in alarm.
Workaround:
None.
|
CSCdv47050
|
Symptom:
The command xcnfalm syntax shows -ds1 <line> instead of -x21 <line>.
Conditions:
Get help on xcnfalm command.
Workaround:
None.
|
CSCdv47076
|
Symptom:
The command xcnfport syntax doesn't show -sig option.
Condition:
Get help on xcnfport.
Workaround:
None.
|
CSCdv47086
|
Symptom:
The command xcnfport syntax description shows unwanted options
Conditions:
Issuing xcnfport with no or illegal parameters
Workaround:
None.
|
CSCdv48190
|
Symptom:
Connection doesn't go into failed state on PXM upon subinterface admin shutdown
Condition : When the subinterface is administratively shutdown, the connection under that subinterfaces should go into fail state or atleaast a failure trap should be sent to indicate no routing can take place. CWM was not getting this Filure trap.
Workaround:
None.
|
CSCdv49617
|
Symptom:
Output of dspapsln is not aligned between the header and APS line status.
Conditions:
Workaround:
None.
|
CSCdv51362
|
Symptom:
Not able to configure bert for lines greater than 8.
Condition:
Unknown.
Workaround:
Unknown.
|
CSCdv53166
|
Symptom:
The clock status is inconsistent between dspcurclk and dspclkinfo .
Conditions:
When all of the following are true:
1. PXM-UI-S3 back-card is used and clock level is Stratum 3.
2. There is a clock-switch from primary due to an bad (incorrect frequency) clock source.
3. There is no Loss Of Action on primary clock interface.
Workaround:
Use dspclkinfo to find the status of the clock.
|
CSCdv53181
|
Symptom:
PXM does not track a good SERVICE MODULE interface clock.
Conditions:
When PXM-UI-S3 back-card is used and clock level is Stratum 3 and the active clock source is SERVICE MODULE.
Workaround:
Use the external clock source, inband or internal oscillator of the UI-S3 back card.
|
CSCdv56345
|
Symptom:
With many ports added on a FRSM-VHS (FRSM-2CT3), addport may fail due to insufficient hardware resources for further ports. However, the display does not show this as the reason.
Conditions:
On the FRSM-VHS (eg FRSM-2CT3) there is a limit of 128 ports for each of - ds1 1-14,43-56 - ds1 15-42
When adding a port that exceeds this limit, the error message does not accurately indicate the cause of the failure.
Workaround:
There is no workaround, this is a limitation of the hardware. The bug is that the display does not give an appropriate error message.
|
CSCdv69785
|
Symptom:
Remote Loopback operation is not blocked by CiscoView on a AUSM 8T1 line while the line is being added.
Conditions:
Add a remote loopback on AUSM8T1, the remote loopback takes effect inspite of an error message.
Workaround:
None.
|
CSCdv73784
|
Symptom:
PXM reset due to LOG task suspension
Conditions:
Unknown.
Workaround:
None. Standby PXM will take over and become active.
|
CSCdv76611
|
Symptom:
Line with soft loop does not go into minor alarm.
Conditions:
Line is added on FRSM-HS2/B using CV with a soft loop. Line is added but does not go into a minor alarms. If the line is modified using CV then it goes into minor alarm.
Workaround:
Modify the line using Cisco View OR add line using CLI.
|
CSCdv76770
|
Symptom:
PXM has a corrupted file system and the card gets reset sometimes
Conditions:
When CWM does a saveallcnf and then renames the file to the same file using different fashion
Workaround:
Switchcc to the standby PXM and format the corrupted PXM.
Further Problem Description:
Customer is using the CWM saveallcnf script to save config. However, due to the vxwork rename limitation. The script will trigger the problem by renaming the file to the same file. Hence, the PXM file system is corrupted and needs to be formated 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 becaus the IMA groups restart on a softswitch as the t1 lines are reprogrammed for the standby going active.
|
CSCdw07261
|
Symptom:
Channel alarms are not propogated after deleting one end of the connection.
Conditions:
CESM-T3/E3 PXM:1.1.41Ac.
Workaround:
Under Investigation.
|
CSCdw07565
|
Symptom:
PXM OC-3 ports (UNI) do not go into alarm when the line is fed Sonet PATH AIS from tester.
Condition:
HP Tester is connected to PXM-1 OC-3 port and Sonet AIS-P cells are injected. Line reports alarm, but, port remains active.
Workaround:
Unknown.
|
Known Anomalies for Platform Software Release 1.2.00 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.2.00 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCdm10722
|
Symptom:
In case of Graceful upgradation of image on SMs, execution of newrev before install is not rejected by PXM. (1) install (2) newrev (3) commit
If these, commands are not given in the above specfied order, we can be in a situation, where we can have two different images ,running on primary /secondary combination. However, on the disk
Conditions:
Execution of above commands not in a specified manner like running newrev before install on PXM.
Workaround:
Assuming, that these commands were given out of order, and now we have two different images, running, on primary / secondary combination.
f1 - Old image version f2 - Newly downloaded image
(1) Reset the secondary card, so that it comes up, with f2. (2) Do a softswitch between the two cards, so that secondary takes over and becomes active. At the same time, primary is reset, and comes up with f2. (3) If you may, you can now, do a softswitch, to revert back to the original primary, to restore normal state.
|
CSCdp00537
|
Symptom:
Shelf Integrated Alarm not updated correctly and traps are not send consistently when fan tray is removed.
Conditions:
When a fan try is removed.
Workaround : None
|
CSCdp55811
|
Symptom:
On the FRSM 2CT3 when a DS3 is enabled, all the 28 DS1s also gets enabled. Then you will see the alarms in the unused lines. The customer had a problem differentiating between this false alarm and the usual alarms.
Conditions:
When only few of the DS1s are used out of a DS3.
Workaround:
Ignore the alarm or add loop from the CPE devices.
Further Problem Description:
The customer also complained that xcnfln does not work. He tried to disable the DS1s that are not in use using the xcnfln. xcnfln command will take only configuration changes for the line. It cannot add or delete a ds1 line. Even though it has options for enable/disable it wont work. The workaround for this false alarm is to put the line in loopback using the xcnfln. By putting the DS1's in loopback the LOF/RAI alarms will be cleared in DS1 line. But the DS1 will be put in local loopback alarm, which is a major alarm in FRSM-2CT3.
Determining the Cause for Alarm: -------------------------------- A DS1 line can go into alarm because of LOF/RAI alarm or the line is in local loopback. This can be determined in two ways viz. CLI or through Cisco Wan Manager(CWM).
CLI: ---- 1. Check the DS3 Lines
mgx585.1.10.VHS2CT3.a > dspalms -ds3
Line AlarmState StatisticalAlarmState ---- ----------- --------------------- 10.1 No Alarms No Statistical Alarms 10.2 No Alarms No Statistical Alarms
(Continued on next page)
|
CSCdp55811 (continued)
|
2. Check the alarms in DS1 line that we are interested in
mgx585.1.10.VHS2CT3.a > dspalm -ds1 30
If the line is in LOF/RAI alarm: LineNum: 30 LineAlarmState: Alarm(s) On -- XmtRAI RcvLOF LineStatisticalAlarmState: No Statistical Alarms
If the line is in local loopback alarm :
LineNum: 30 LineAlarmState: Alarm(s) On -- LocalLoopback LineStatisticalAlarmState: No Statistical Alarms
If the line is in no alarm :
LineNum: 30 LineAlarmState: No Alarms LineStatisticalAlarmState: No Statistical Alarms
CWM: ---
The steps shown here are wrt Cisco Wan Manager Release 10.3.SOL(Patch2)
1. Select the Node and start the Cisco View Application. 2. Select the Service Moudle Card and the DS3 Line no. - A New window pops up showing the DS3 line configuration. 3. Select the "Physical Line Alarm Config(dsx3)" Category. - Verify that the Line Alarm State and Line Statistical Alarm State is Clear 4. Select the "Channelized Line Config" Category. - A new window pops up with entries for all DS1 lines. - Verify that the the line in question is enabled. 5. In the new window select the "Channelized line Alarm Config(dsx1)" Category - If the line is in loopback the Line alarm state for the DS1 line in question is "Near End Local Loopback in effect". - If the line is in physical level alarm the Line State alarm will be "Transmitting RAI Receiving OOF alarm".
To put the DS1 line in Local Loopback: --------------------------------------
CWM: ---- 1. Select "Channelized Line Config(dsx1)" Category in the new window. 2. Go to the DS1 line in question. 3. Go to the lineloopbackCommand column and click and select dsx1LocalLoop. 4. Go to the lineEnable column and click and select modify 5. Click the Apply button 6. First close the old window and select the "Channnelisex line Config" Category in the old window. 7. After the display gets refreshed, verify that the lineLoopBackCommand for the DS1 line is "dsx1LocalLoop". 8. Also verify it in the "Channelized line Alarm Config(dsx1)" Category
CLI: ----
mgx585.1.10.VHS2CT3.a > xcnfln -ds1 30 -e 3 -lpb 3
mgx585.1.10.VHS2CT3.a > dspalm -ds1 30
LineNum: 30 LineAlarmState: Alarm(s) On -- LocalLoopback LineStatisticalAlarmState: No Statistical Alarms
mgx585.1.10.VHS2CT3.a > dsplns
(dsplns will have the entry for DS1 30 as )
10.30 dsx1ESF Mod LocalTimin LocalL Yes No
|
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 continously change state.
Workaround:
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 are 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.
|
CSCds28525
|
Symptom:
The alarm status for the connection shown at CESM and PXM donot match. The clis tstcon and tstdelay fails for these connections.
Conditions:
One of the identifed conditions is that this problem appears for a low partial-fill value.
Workaround:
Assigning the partial-fill value of 47 sometimes solves the problem.
|
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 where Code Violations..
|
CSCds86780
|
Symptom:
The commands dspcd, dspln, dsplns, dspport, dspports, dspco, dspcons never prompt after adding multiple 3 seg connections.
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.
|
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.
|
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
The command 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 an 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 enven 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: 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.
|
CSCdu22992
|
Symptom:
The message did not occur in CWM event log when standby PXM had H/W issue.
Conditions:
Unknown.
Workaround:
Unknown.
|
CSCdu26221
|
Symptom:
MIB files are 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. The command dsportcnt will show LMI signalling timeouts, data incrementing only in the Tx direction. Port will register LMI failure.
Conditions:
Unknown.
Workaround:
Card reset.
|
CSCdu36591
|
Symptom:
The CWM does not display the correct values of Ingress Percentage Utilization Egress Percentage Utilization Connection Percentage Utilization Connection Remote Percentage Utilization
Conditions:
These mib objects are not included in the TFTP config upload file.
Workaround:
No workaround.
Further Problem Description:
Problem Investigation details:
At prsent CWM is setting %util values( lper_util, rper_util) to -1.
CWM will get these values from
* TFTP config UpLoad File * SNMP UpLoad file.
CWM will parse these values and update Database.
For FSRM(4T, 4E, 8T, 8E..) , AUSM , VISM , CESM cards we are not getting lper_util & rper_util values in TFTP upload and SNMP upload fiels.
But these values are there on CLI.
It is required to have these %util values in TFTP & SNMP config Upload files for all cards, so that CWM can prase these values and populate in DataBAse
|
CSCdu38671
|
Symptom:
Clock controller running on internal oscillator after upgrade.
Conditions:
After upgrade from 1.1.23 to 1.1.34.
Workaround:
Reconfigure the clock. For the current senario, 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 transferr stopped for approx 1min, 25 secs.
Conditions:
Upon SRM active backcard removal.
Workaround:
None.
|
CSCdu45324
|
Symptom:
Traffic test using gn netester inputting 60cps across 500 SIW connections built from BPX network running 9.2.37 and passing through two ATM nni gateways and terminating on a PXM1 feeder and FRSM card. Shows dicards on FRMS due to CRC and assembly errors. PXM1 running 1.1.32
This mainly occurs on the last 5 ports of the FRSM.
Conditions:
FRSM heavily loaded.
Test environment
Workaround:
None.
|
CSCdu46419
|
Symptom:
With UBR connection, observed GCRA2 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 cells on the ingress.
Workaround:
None so far.
|
CSCdu48231
|
Symptom:
Ilmi failure on ports while traffic continuity
Condition:
When ilmi keep alive option is turned ON for the port.
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 es 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:
The command 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:
The commands 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.
|
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.
|
CSCdu79023
|
Symptom:
Reset of primary PXM is allowed even if secondary card is not available.
Conditions:
Always.
Workaround:
Always use switchcc instead of resetcd to make sure whether the redundancy is available or not.
|
CSCdu82493
|
Symptom:
On a CBR connection SCR and MBS shows numeric values. This should be N/A
Conditions:
Not applicable.
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.
|
CSCdu86525
|
Symptom:
PXM1 resets due to watchdog timeout reset.
Conditions:
Unknown.
Workaround:
Mone. This problem is a pure software issue and there is no need to replace hardware. PXM will reset due to watchdog timeout and come up to active/standby state.
Further Problem Description:
Software exceptions due to unknown reason. From the current exception logs in the core, it is not sufficient to decide the root cause of the first exception. However, the events after the first exception showed some flaws in design.
|
CSCdv01949
|
Symptom:
Line goes into alarm. cnfln accepts line code as AMI for CESM-8E1 with CCS.
Conditions:
Line is configured as AMI.
Workaround:
This happens only if there is end to end loopback. If at least on one end, we send a valid traffic on the line, instead of having a loopback, the alarm will go away.
|
CSCdv11015
|
Symptom:
No Sonet option under the xcnfalm command
Conditions:
Normal operation.
Workaround:
Not applicable.
|
CSCdv17041
|
Symptom:
Command line interface on the AUSM is not standard and you have two options to have a VPC either VPI,0 or just VPI and then the second option will only work once.
Conditions:
Trying to add a VPC connection.
Workaround:
None.
|
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
|
CSCdv40282
|
Symptom:
If multiple SMs which are a part of different redundnacy groups are reset at the same time and also the PXM switch-over happens, some SMs goes into mismatch/failed state
Conditions:
Multiple card failure with PXM
Workaround:
Reset the card which is stuck in Failed/mismatch state.
|
CSCdv44392
|
Symptom:
If a currenly 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 dspcurclk 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 command output for the correct information on currently active clock sources.
|
CSCdv45151
|
Symptom:
AUSM line reports a LOF when doing BERT testing
Conditions:
When bert is configured on an AUSM line.
Workaround:
None.
|
CSCdv45747
|
Symptom:
More cells are lost when the secondary SM of a redundant set is active on PXM switchover.
Conditions:
When the secondary AUSM is active and a PXM switchover takes place.
Workaround:
None known.
|
CSCdv48510
|
Symptom:
1. Active core card set SRM showing 'mismatch' because of missing back card.
2. Standby core card set PXM showing 'mismatch' because it has SRM card.
3. Unable to switchcc because core card set not available.
4. After inserting the SRM backcard, get message 'PXM Switchover for SRM Failure' on the active PXM but it does not switch.
Condition:
Pull out standby SRM back card.
Workaround:
Insert standby SRM back card.
|
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 Ingress State : normal
Channel Egress State : normal
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
|
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.
|
CSCdv53678
|
Symptom:
The switchapsln clear comamnd 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:
Issue the command 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.
|
CSCdv62135
|
Symptom:
bootChange command should have password authentication
Conditions:
Workaround:
None.
|
CSCdv69491
|
Symptom:
When two lines on the same AUSM card are connected to each other with only one line enabled, the other line will be in alarm. But if you reset the card, alarm goes away.
Conditions:
Lines on the same card.
Workaround:
None.
|
CSCdv76409
|
Symptom:
abrfst PVCs on AUSM not rating down to MCR when run over congested BXM.
Conditions:
Lab environment. Manufactured congestion.
Workaround:
Configure IBS = 0
|
CSCdv79466
|
Symptom:
Sometimes oldiag fails on standby PXM.
Condition:
oldiag fails attempting IPC with the standby PXM. Node is placed in major alarm due to the standby PXM oldiag failure.
Workaround:
None.
|
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:
Err: cliCroiPsrWrite(): ipc_open_port_by_name(RPM Slot 10:Console):
failed
WorkAround:
None.
|
CSCdv81736
|
Symptom:
SM Card in reset loop.
Conditions:
Previously saved PRI File downloaded to the switch. Connections provisioned after this.
Workaround:
Reset the card after the PRI file download.
|
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.
Further Problem Description:
None.
|
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.
Further Problem Description:
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.
|
CSCdv89742
|
Symptom:
The command clralmcnt -ds3 does not clear the counters for the SRM.
Conditions:
Workaround:
Use clralms -ds3.
|
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; 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 messageas 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:
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)
|
CSCdw00713
|
Symptom:
Major Communication Failure on trunk between 8250 and IGX.
Conditions:
Trunk between 8250 and IGX is in Major Communication Failure causing the feeder to be unreachable.
Workaround:
None.
|
CSCdw01087
|
Symptom
Switchover time > 250ms when either SRM/E FC or BC is removed
Condition
When ever we remove the FC of SRM/E the switch over time is greater than 250ms. It should be less than 250ms.
Workaround
Currently it looks like it is a hardware problem. While accessing one of the registers it is taking time. Still debugging with hardware engineers.
|
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.
|
CSCdw02483
|
Symptom:
Couldn't add maximum number of connections on FRSM-HS2/B card.
Conditions:
clrsmcnf was done.
Workaround:
Under investigation.
|
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 popluated with VISM and AUSM Cards.
Workaround:
Confirm the standby has updated database and execute a swithcc
Further Problem Description:
None.
|
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.
|
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. Probablity 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 configued for lmi (annexd/or annex a) reserved dlic cannot be coinfigured as expected.
Conditions:
When a connection is added with a reserved DLCI value and a port which has signalling configured.
Workaround:
Do not add the connections with reserved DLCI.
|
CSCdw03737
|
Symptom:
The connection from FRSM-2CT3 to FRSM-8T1 through BPX cloud, does not pass traffic. The command 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.
|
CSCdw09173
|
Symptom:
Channel state on the CWM GUI is inconsistent with that of the switch
Condition:
It happens under the following sequence of events - Channel fails due to Abit alarm - Port for that channel fails - Port for that channel clears
Workaround:
None.
Further Description:
When the above mentioned conditions happen then the CWM database will show the connection state as OK instead of Fail as in the switch. To circumvent this problem, with the current implementation of CWM, the switch needs to send channel traps for all the failed channels once the port comes up.
|
CSCdw09234
|
Symptom:
The lines of Service Moduel 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 expericing 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.
|
CSCdw10286
|
Symptom:
CESM T3E3 card goes into Major alarm after incorrect addcon
Conditions:
addcon 1 2 on the CESM T3E3 card
Workaround:
If the card into alarm, do a clrsmcnf and issue addcon 1 for a slave connection.
|
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.
|
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 slot.
|
CSCdw20626
|
Symptom:
T3E3 card does not show card minor alarm when connection is in alarm because of cell loss.
Conditions:
cell Loss alarm on a connection. This can be caused as a result of 1. A bit alarm on a connection 2. Errors in the transmission of the data.
Workaround:
None Further Problem Description:
None
|
CSCdw23460
|
Symptom:
Traffic not passing on FRSM-8T1 card (in bulk mode) after two softswitch(s)
Conditions:
This applies to all cards supporting 1:N redundancy. The card that is the configured as the secondary card should have had been previously configured with a connections. Failover or softswitch to the secondary and back to the primary will cause traffic outage
Workaround:
Switch to the secondary card. Do not configure a card as secondary (1:N) if it has been previously active with connections.
|
CSCdw24512
|
Symptom:
PXM continuous reboots, with tRootask failure.
Condition:
DB corruption
Workaround:
ename/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.
|
Compatibility Notes
MGX 8230/8250/8850 Software Interoperability with Other Products
Platform Software:
|
PXM 1.2.00
|
Compatible BPX Switch Software:
|
In 9.2 Baseline, Switch Software 9.2.30 and higher
In 9.3 Baseline, 9.3.35 and higher
|
Compatible MGX Release 2 Switch Software:
|
MGX Rel. 2 Software 2.0.15 and 2.1.70
|
Network Management Software:
|
10.5.10
|
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.04.fw1
|
468228
|
pxm_bkup_1.2.00.fw
|
1341296
|
rpm-boot-mz.122-4.T1
|
2621704
|
vism_8t1e1_VI8_BT_3.0.00.fw
|
248400
|
VISM and RPM Firmware Compatibility
The following firmware compatibility matrix is for this release.
Table 12 VISM, CWM and RPM Firmware Compatibility Matrix
PCB Descriptions
|
CW2000 Names
|
Latest F/W
|
Min F/W
|
File Name
|
File Size (in bytes)
|
MGX-VISM-8T1 and MGX-VISM-8E1
|
VISM-8T1 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-mz .122-4.T1 (IOS)
|
8584068
|
MGX 8250/8850 Firmware Compatibility
The following firmware compatibility matrix is for this release.
Table 13 MGX 8250 Switch and MGX 8850 Switch Firmware Compatibility Matrix
PCB Description
|
CW2000 Name
|
Latest F/W
|
File Name
|
File Size (in bytes)
|
PXM1
|
PXM-1
|
1.2.00
|
pxm_1.2.00.fw
|
2553428
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.2.00
|
pxm_1.2.00.fw
|
2553428
|
PXM1-4-155
|
PXM1-4OC3
|
1.2.00
|
pxm_1.2.00.fw
|
2553428
|
PXM1-1-622
|
PXM1-OC12
|
1.2.00
|
pxm_1.2.00.fw
|
2553428
|
MGX-SRM-3T3/B
|
SRM-3T3
|
—
|
—
|
—
|
MGX-SRM-E
|
SRM-E
|
—
|
—
|
—
|
AX-CESM-8E1
|
CESM-8E1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
AX-CESM-8T1
|
CESM-8T1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
MGX-CESM-8T1/B
|
CESM-8T1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
MGX-CESM-T3
|
CESM-T3
|
10.2.00
|
cesm_t3e3_10.2.00.fw
|
607792
|
MGX-CESM-E3
|
CESM-E3
|
10.2.00
|
cesm_t3e3_10.2.00.fw
|
607792
|
MGX-AUSM-8E1/B
|
AUSMB-8E1
|
10.2.00
|
ausm_8t1e1_10.2.00.fw
|
1310364
|
MGX-AUSM-8T1/B
|
AUSMB-8T1
|
10.2.00
|
ausm_8t1e1_10.2.00.fw
|
1310364
|
AX-FRSM-8E1/E1-C
|
FRSM-8E1
|
10.2.00
|
frsm_8t1e1_10.2.00.fw
|
833236
|
AX-FRSM-8T1/T1-C
|
FRSM-8T1
|
10.2.00
|
frsm_8t1e1_10.2.00.fw
|
833236
|
MGX-FRSM-HS2/B
|
FRSM-HS2/B
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-HS2
|
FRSM-HS2
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2CT3
|
FRSM-2CT3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2T3E3
|
FRSM-2T3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2T3E3
|
FRSM-2E3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-HS1/B
|
FRSM-HS1/B
|
10.2.00
|
frsm_hs1_10.2.00.fw
|
763532
|
MGX 8230 Firmware Compatibility
The following firmware compatibility matrix is for this release.
Table 14 MGX 8230 Firmware Compatibility Matrix
PCB Description
|
CW2000 Name
|
Latest F/W
|
File Name
|
File Size (in bytes)
|
PXM1
|
PXM-1
|
1.2.00
|
pxm_sc_1.2.00.fw
|
2550312
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.2.00
|
pxm_sc_1.2.00.fw
|
2550312
|
PXM1-4-155
|
PXM1-4OC3
|
1.2.00
|
pxm_sc_1.2.00.fw
|
2550312
|
PXM1-1-622
|
PXM1-OC12
|
1.2.00
|
pxm_sc_1.2.00.fw
|
2550312
|
MGX-SRM-3T3/B
|
SRM-3T3
|
—
|
—
|
—
|
MGX-SRM-3T3/C
|
SRM-3T3
|
—
|
—
|
—
|
MGX-SRM-E
|
SRM-E
|
—
|
—
|
—
|
AX-CESM-8E1
|
CESM-8E1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
AX-CESM-8T1
|
CESM-8T1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
MGX-CESM-8T1/B
|
CESM-8T1
|
10.2.00
|
cesm_8t1e1_10.2.00.fw
|
700496
|
MGX-CESM-T3
|
CESM-T3
|
10.2.00
|
cesm_t3e3_10.2.00.fw
|
607792
|
MGX-CESM-E3
|
CESM-E3
|
10.2.00
|
cesm_t3e3_10.2.00.fw
|
607792
|
MGX-AUSM-8E1/B
|
AUSMB-8E1
|
10.2.00
|
ausm_8t1e1_10.2.00.fw
|
1310364
|
MGX-AUSM-8T1/B
|
AUSMB-8T1
|
10.2.00
|
ausm_8t1e1_10.2.00.fw
|
1310364
|
AX-FRSM-8E1/E1-C
|
FRSM-8E1
|
10.2.00
|
frsm_8t1e1_10.2.00.fw
|
833236
|
AX-FRSM-8T1/T1-C
|
FRSM-8T1
|
10.2.00
|
frsm_8t1e1_10.2.00.fw
|
833236
|
MGX-FRSM-HS2
|
FRSM-HS2
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-HS2/B
|
FRSM-HS2/B
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2CT3
|
FRSM-2CT3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2T3E3
|
FRSM-2T3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-2T3E3
|
FRSM-2E3
|
10.2.00
|
frsm_vhs_10.2.00.fw
|
977684
|
MGX-FRSM-HS1/B
|
FRSM-HS1/B
|
10.2.00
|
frsm_hs1_10.2.00.fw
|
763532
|
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
|
APS
|
|
|
|
|
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
|
APS on controller card
|
Supported in a future release.
|
Switching Capacity
|
8220
|
8230
|
8250
|
8850
|
|
320 Mbps
|
1.2 Gbps
|
1.2 Gbps
|
1.2 Gbps
|
|
Trunk/Port Interfaces
|
8220
|
8230
|
8250
|
8850
|
T3/E3
|
1
|
2 (one feeder trunk)
|
2 (one feeder trunk)
|
2
|
OC-3c/STM-1
|
1
|
4 (one feeder trunk)
|
4 (one feeder trunk)
|
4
|
OC-12c/STM-4
|
No
|
1
|
1
|
1
|
OC-48c/STM-16
|
No
|
No
|
No
|
No
|
n x T1/E1
|
Yes
|
Yes
|
Yes
|
Yes
|
|
Front Cards
|
8220
|
8230
|
8250
|
8850
|
AX-FRSM-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8T1-C
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8E1-C
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-HS2
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-HS2/B
|
No
|
Yes
|
Yes
|
Yes
|
AX-FRSM-HS1
|
Yes
|
No
|
No
|
No
|
MGX-FRSM-HS1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-2T3/E3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-2CT3
|
No
|
Yes
|
Yes
|
Yes
|
AX-AUSM-TE1
|
Yes
|
No
|
No
|
No
|
MGX-AUSM-8T1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-AUSM-8E1
|
Yes
|
No
|
No
|
No
|
MGX-AUSM-8E1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-IMATM-8T1/B
|
Yes
|
No
|
No
|
No
|
AX-IMATM-8E1/B
|
Yes
|
No
|
No
|
No
|
AX-CESM-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-CESM-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-CESM-T3E3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-CESM-8T1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-SRM-T1E1/B
|
Yes
|
No
|
No
|
No
|
AX-SRM-3T3
|
Yes
|
No
|
No
|
No
|
MGX-SRM-3T3/B
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-SRM-3T3/C
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-SRM-E
|
No
|
Yes
|
Yes
|
Yes
|
MGX-VISM-8T1
|
No
|
Yes
|
Yes
|
Yes
|
MGX-VISM-8E1
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RPM-128/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RPM-PR
|
No
|
Yes
|
Yes
|
Yes
|
PXM1
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-2T3E3
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-4-155
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-1-622
|
No
|
Yes
|
Yes
|
Yes
|
|
Back Cards
|
8220
|
8230
|
8250
|
8850
|
AX-SMB-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-RJ48-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-RJ48-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-SMB-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-RJ48-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-RJ48-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-SCSI2-2HSSI/B
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-12IN1-4S
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-12IN1-8S
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2T3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2E3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2E3A
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-3T3-M
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-UI
|
No
|
Yes
|
Yes
|
Yes
|
PXM-UI-S3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-MMF-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
OC3/STM1
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFIR-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFLR-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFIR-1-622/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFLR-1-622/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RJ45-FE
|
No
|
Yes
|
Yes
|
Yes
|
MGX-MMF-FE
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RJ45-4E
|
No
|
Yes
|
Yes
|
Yes
|
RPM Compatibility Matrix
MGX SW version
|
1.1.32
|
1.1.34
|
1.1.40
|
1.2.00
|
"Bundled" IOS SW version
|
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.2(2)T2
|
12.2(4)T
|
12.2(4)T1
|
CWM
|
10.4.01
|
10.4.01 Patch 1
|
10.5
|
10.5.10
|
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 ciurrent 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, refer to Instructions to Abort PXM Upgrade.
Special Instructions for Networks Containing FRSM 2 CT3
When upgrading from any release prior to Release 1.1.32, under certain conditions with the FRSM 2 CT3, a script must be ran in order to properly upgrade the software. The script resolves the FREEDM buffer issue described in anomaly CSCds66176; namely, that ports are lost sometimes after softswitch or resetcd. The algorithm to allocate FREEDM buffers was changed in order to fix this anomaly. Because of the algorithm change, ports might be lost when upgrading from a release (FRSM version < 10.0.22) with the older algorithm. The script identifies cards which will lose ports if the card is upgraded to Release 1.1.32 or greater.
A README file contained in the Release bundle TAR file located on CCO describes how to run the script and shows an example of the script output.
Executing the Script
Execute the script:
•On all shelves with FRSM-2CT3 prior to an upgrade from any version to Release 1.1.32 (FRSM VHS version 10.0.22) or higher.
•For upgrades from releases prior to Release 1.1.32 for the MGX 8250, MGX 8230, or MGX 8850. To fix this issue, an algorithm change was made in Release 1.1.32 (10.0.22 version of FRSM 2 CT3).
Script Functionality
The script applies the new algorithm for buffer allocation to existing ports to determine if all the ports will remain intact during the upgrade process. After application of the new algorithm, a log file is created for each FREEDM chip on all the FRSM 2CT3 cards on the shelf. The log file contains confirmation that the buffer allocations are OK or NOTOK. If the log file contains NOTOK for a card, then upgrading the card to the new release will cause the card to lose ports. Therefore, ports must be moved to another card before upgrading this card.
Single PXM Installation Procedure
Step 1 Save your current configuration.
Step 2 Get the filename by listing the CNF directory:
-------- ------ ------ --------
512 APR-08-1999 08:16:18 . <DIR>
512 APR-08-1999 08:16:18 .. <DIR>
512 APR-09-1999 05:26:42 TMP <DIR>
45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip
45433 APR-09-1999 05:28:42 NODENAME.zip
total space : 819200 K bytes
free space : 787787 K bytes
Step 3 On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp shelf.ip.address
tftp> get CNF/NODENAME_0409990528.zip
Received 45433 bytes in 0.4 seconds
Step 4 Download the release to upgrade PXM Backup boot image to the PXM . For example:
unix-prompt> tftp <node_name or IP address>
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
Step 5 Download the release to upgrade PXM runtime image to the PXM. For example:
tftp> <node_name or IP address>
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
Step 6 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Use the TFTP put command:
tftp <node_name or IP address>
Step 7 On the PXM type the following when the transfer is done:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 8 Execute install bt <new_rel>.
Step 9 Execute install <new_rel>. At the end of the display, enter yes.
redundancy is not available
the other card is not available
you are not in redundant mode,
do you want to try an ungraceful upgrade
Installation Procedure for Redundant PXMs
This section applies to upgrades from 1.1.23 and all later releases.
Caution Do not remove old firmware until the upgrade is done.
Note First you must ensure that the shelf IP address and the PXM IP address are set. The PXM must have its own unique IP address and there must be a another unique IP address for the shelf.
To set the PXM address, use the bootChange command:
'.' = clear field; '-' = go to previous field; ^D = quit
inet on ethernet (e) : 172.29.37.220: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. Use the TFTP put command:
unix-prompt> tftp <node_name or IP address>
Step 8 After the transfer is done, type the following on the PXM:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 9 Execute the command install bt <new_rel>.
Step 10 Execute the command install <new_rel>.
Step 11 After the Standby card is reset and successfully enters the hold state, on the Active PXM, execute the command newrev <new_rel>.
The Active card will be reset and go to hold state.
After the newrev, use the command dspcd to show the firmware revision onthe new, active PXM.
During the graceful upgrade procedure, if after the newrev command the non-active card enters the "MISMATCH" state, do the normal commit command. You will get a warning message:
other card not found,
do you still want to complete the commit operation
Answer yes and then reset the non-active card.
If you get the MISMATCH during the upgrade process, after you finish, you will still have the MISMATCH. To correct the mismatch, you must check your back cards; they must be identical.
Step 12 After the Active PXM is reset and successfully enters the hold state, on the new Active PXM, execute commit <new_rel>.
Instructions to Abort PXM Upgrade
A graceful downgrade is not supported. However, abort or fallback to the previous release is supported at any stage during the upgrade. The following procedure should be used to abort to a previous release.
Upgrade from Release 1.1.3x
If the upgrade needs to be aborted for any reason during the upgrade process, follow these instructions.
Step 1 Execute abort <release no>
PXM.a> abort <release no>
Upgrade from Release 1.1.2x
If the upgrade needs to be aborted for any reason during the upgrade process, follow these instructions.
Step 1 If the abort is required before the newrev command is entered, skip to Step 2.
a. Execute the following commands if the upgrade process is past the newrev stage.
b. On the Active PXM, execute shellConn
c. Execute smCardMibVer = 21
d. Execute saveDBToArchive <PXM SlotNo>, 0
e. Execute uploadBram <PXM SlotNo>, <PXM SlotNo>
The <PXM SlotNo> should be 7 for the MGX8850 Switch and for the MGX 8250 Switch (even if the Active PXM is in slot 8, use slot 7).
The <PXM SlotNo> should be 1 for the MGX8230 Switch (even if the Active PXM is in slot 2 use slot 1).
The example that follows is for the MGX8850.
f. If RPM cards also are on this node, perform the following for each RPM card:
Inside shellConn on Active PXM, execute:
saveDBToArchive <RPM_slot#>, 1
d &arcMem+<RPM_slot#>*4
Copy down the 4 byte address that is displayed after executing the d&arcMem+<RPM_slot#>*4
command and enter it in the following command.
rmSlotArchFileSave <RPM_slot#>, <4 byte address>
For example, for an RPM in slot 9, the result is:
8051cb90: 8702 bad8 0000 0000 0000 0000 * ..........*
8051cba0: 0000 0000 0000 0000 0000 0000 0000 0000
-> rmSlotArchFileSave 9,0x8702bad8
Step 2 Execute abort <release no>.
PXM.a> abort <release no>
Service Module Boot/Firmware Download Procedure
The following procedure describes how to download the boot and the service module firmware for slot-independent and slot-dependent images.
Step 1 Download the boot image for the service module onto the PXM hard disk.
unix-prompt> tftp <node_name or IP address>
tftp> put <backup boot> POPEYE@SM_1_0.BT
Step 2 Download the boot image onto the respective service module using the command:
install bt sm <slot #> <version>
Repeat for each of the service modules on the node.
Step 3 Now, choose instruction for slot-independent or slot-dependent firmware. See below.
For slot-independent image:
Download the selected revision of service module firmware onto the PXM hard disk.
unix-prompt>tftp <node_name or IP address>
tftp> put <FW file> POPEYE@SM_1_0.FW
You cannot do two puts in the same TFTP session.
Repeat for each service module type and for each slot-independent firmware.
For slot-dependent image:
For a slot-specific image (in this example the service module is tied to slot 1),
unix-prompt> tftp <ip address of the MGX 8850 shelf>
tftp> put <sm FW file name> POPEYE@SM_1_1.fw
Note If the checksums are not the same when you remove the service module then the service module will not boot when it is plugged in and the service module will have to be RMA'ed.
Note Please consult your Support Representative before performing any software upgrade.
Manual Configuration of Chassis Identification
MGX as a Standalone Node
If any MGX box is to be used as a standalone node for testing, the intended model number from the PXM firmware configuration should be matched MANUALLY by running the "runConfigurator" utility.
Example: ipfrnj40 was running 1.1.24 as a 8850 node:
If the node's model number is set to 8250 by default after a 1.1.32 firmware upgrade, but the ipfrnj40 is still configured as a 8850 standalone node on the CWM side, then CWM will reject the node on discovery, and the node will remain undiscovered.
Solution: On every standalone node, manually verify that the runConfigurator settings match the switch.
Chassis Identification During a Firmware Upgrade
On the CWM side, the emd.conf must be modified to a one second wait time so it can help clean up the emc process's internal cache and CWM database (regarding any slot that has sent the functional removal trap). This ensures that CWM will sync up whatever is current with the switch after the upgrade.
Before a firmware upgrade is begun, complete the following steps:
Step 1 Change the following line in emd.conf:
"Hold for 300 secs before deleting the card after a func module trap is received".
to
"Hold for 1 secs before deleting the card after a func module trap is received".
Note This prevents race conditions in updating the database table from the firmware version upgrade.
Step 2 After emd.conf is changed, send HUP signals to all EMC processes.
Step 3 After the firmware upgrade is complete, reset the hold time back to 300 seconds.
Step 4 Send HUP signals to EMC processes to confirm the changeback.
Interoperability of Service Module on MGX 8220 and MGX 8250 Switches
Caution Graceful downgrade for the Service Module is not supported.
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.
SPARE DEPOT: Customers receiving a replacement service module via the TAC (through the RMA process) will have the common boot code image that works for MGX 8220 Release 4.x, 5,x, and MGX 8850 installed on legacy service modules. (Spare service modules received directly from manufacturing through the normal ordering process will have the correct boot code image already loaded.)
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration Guide on the documentation CD.
Use ftp to port the Axis 5 common boot image for the service module to a workstation.
Plug in the card into the MGX 8220 shelf.
Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
unix-prompt> tftp <ip address of the MGX 8220 shelf >
1tftp> put <boot filename> AXIS_SM_1_<slot#>.BOOTkj
Now you must insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Login to the shelf.
unix-prompt> tftp cc <slot #>
Verify that the two checksums are the same.
If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Service Module Upgrades
The following steps need to be followed for service module upgrades. Service module firmware images cannot be downloaded as specific versions, because only 1 slot independent image can be present on the disk. Hence, the user cannot revert back during the installation process.
Step 1 Download the service module firmware to the shelf. Refer to Service Module Boot/Firmware Download Procedure.
Note To upgrade all the service modules, load all the firmware files and boot files to the node. Then execute the command resetsys. Make sure that the configuration is saved.
Step 2 For non-graceful upgrades, just reset the card and the service module will come up with the new image.
Step 3 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)T or higher is used with MGX Release 1.2.00. This IOS release supports new 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 MGX-RPM-128M/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 anomally 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.)
•MGX-RPM-128M/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 14contains cautions important to the successful usage of the bypass feature.
Table 15 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:
5. From the PXM hard-drive.
6. From the boot flash.
7. From the network (e.g. via TFTP) from the RPM backcard (Ethernet or Fast Ethernet).
When the bypass feature is enabled, the "boot config" statement:
c:auto_config_slot## is automatically generated. The NVRAM configuration is cleared upon a "write memory". In order to load from the network, the RPM has to have an IP address for its backcard. This information is part of the NVRAM configuration, which was just cleared by enabling the bypass feature. Hence, it is not possible to load the IOS image from the network upon a reload of the RPM after the "rpmnvbypass" and "write memory" have been executed.
|
Do not execute the command no boot config because doing so may prevent the bypass feature from working properly.
|
When the bypass feature is enabled, the "boot config" statement:
is automatically generated, and the NVRAM configuration is cleared.
Any writes now are directed to the "boot config" file. This is essential, as a "write memory" expects the "boot config" statement to be present.
If the "boot config" statement isn't present, it would write the configuration into the NVRAM, which of course, is not desirable when the objective is to save a complete configuration when the configuration is large and requires more space.
|
If the command write memory is issued with the bypass feature enabled, and is consequently followed by an RPM card reset, previous versions of the boot image will trigger the RPM card to go into boot mode (unable to load run-time IOS).
|
For safety purposes, the location of the system image is stored in a special area (called the ROMMON area) in the NVRAM. The ROMMON is always intact.
The 12.2(4)T boot image accesses and reads ROMMON in order to load the IOS image. Boot images prior to 12.2(4)T do not read the ROMMON area.
Generally, the IOS boot and run-time images are of the same versions. However, if the user changed his boot image to one prior to 12.2(4)T, on a reload, the boot image would see that the NVRAM configuration is empty (of course, this is normal when the bypass feature is enabled). However, since boot images prior to 12.2(4)T cannot access the ROMMON area, it cannot read there the location of the IOS image. Unable to see the IOS image, it instead loads itself.
|
Example 1 through Example 5 illustrate how the bypass feature is enabled and disabled, and how to validate each of these actions from the configuration display.
Example 1 Running configuration without the bypass feature enabled
rpm_slot02#show running-config
Building configuration...
Current configuration : 470 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.<new_rel>
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.<new_rel>
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.<new_rel>
boot config c:auto_config_slot02
snmp-server community public RO
snmp-server community private RW
Refer to Route Processor Module (RPM) Addendum for more specific information about the RPM.
Upgrading from an MGX-RPM-128M/B Card to an RPM-PR Card
To replace an MGX-RPM-128M/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 MGX-RPM-128M/B card.
Step 6 Verify the following before inserting the RPM-PR in the node:
•PXM must be running a minimum firmware release of 1.1.34.
•PXM disk contains the latest IOS image specified for the RPM-PR.
Caution Once an MGX-RPM-128M/B card is replaced with a RPM-PR card, the MGX-RPM-128M/B card can not be re-installed. If an attempt is made to re-install the MGX-RPM-128M/B, the module will be put into 'Mismatch'.
Caution After installing the 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.
Related Documentation
Note that for Release 1.2.00, the product documents (Command Reference, Overview, and Installation and Configuration Guides) were not updated. Use the Release 1.1.3 documents in addition to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.2.00.
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 URL:
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. Follow the instructions at the top of the documentation page, prompting you to "Click here" to link to the Documentaion Survey form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL:
http://www.cisco.com
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
http://www.cisco.com/go/subscription
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:
http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC are categorized according to the urgency of the issue:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the Cisco WAN Switching MGX 8850 Release 1, MGX 8250, and MGX 8230 publications.
Copyright © 2002, Cisco Systems, Inc.
All rights reserved.