Guest

Cisco MGX 8800 Series Switches

1.1.00 Version Software Release Notes, Cisco MGX 8850

 Feedback

Table Of Contents

1.1.00 Version Software Release Notes
Cisco WAN MGX 8850 Software

About These Release Notes

IMPORTANT NOTE

About the 1.1.00 Release

FEATURES

MGX 8220 Hardware not supported on Release 1.1.00 of the MGX 8850

MGX 8220 Hardware that has been superseded on the MGX 8850 by MGX 8850-specific Hardware

MGX 8220 Hardware that will not be supported on the MGX 8850

3. Software Platform Features

Features not supported in this release:

Major Network Management Features

Connection Limits

SNMP MIB:

Notes & Cautions

Limitations

Problems Fixed for RPM in 12.0.4T

Documentation

Compatibility Notes

Location of RPM Images on CCO:

Special Installation and Upgrade Requirements

Single PXM Installation Procedure

Installation Procedure For Redundant PXMs:

PXM Flash Download Procedure

Service Module Firmware Download Procedure

Service Module Installation/Upgrade and Flashdownload Requirements.

PXM Software 1.0.00 to 1.1.00 Upgrade Procedure

FOR REDUNDANT PXM SYSTEMS TO BE UPDATED ALL AT ONCE (ONE LONG OUTAGE - THIS IS NOT GRACEFUL)

Known Anomalies for Platform Software and Service Module Firmware

Known Anomalies for RPM

Obtaining Service and Support

Cisco Connection On-line


1.1.00 Version Software Release Notes
Cisco WAN MGX 8850 Software


About These Release Notes

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

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

IMPORTANT NOTE

PXM core card redundancy is supported in this release.

The MGX user documentation describes several features and service modules that are not supported in this release (APS, CESM 3T3). Refer to the "Documentation" section for a list of affected commands.

About the 1.1.00 Release

MGX 8850 Release 1.1.00 supports the same network scenarios as Release 1.0.00

1 Feeder concentration to the BPX 8600 (no IGX 8400 series interoperability or BPX 8600 BNI trunk connections):

The MGX 8850 provides multiservice, high density ATM, Circuit Emulation and Frame Relay feeder concentration to the BPX 8600. MGX 8850 connects to the BPX 8600 using the feeder trunk protocol over a PXM port. On the BPX 8600 side feeder connection trunk to MGX 8850 is supported on the BXM card only. Interoperability support is limited to (a) MGX 8850 to MGX 8850, (b) MGX 8850 to MGX 8220, and (c) MGX 8850 to BPX 8600 (FR to ATM service interworking).

2 MGX 8850 in a Stand-alone Concentrator configuration

Stand-alone capability allows the MGX 8850 to act as edge concentrator to any vendor ATM network which implies service interoperability with other vendor's equipment. All connections for stand-alone are local switching connections.

FEATURES

MGX 8850 Release 1.1.00 provides the following additional hardware and features (in addition to the ones provided in Release 1.0.00)

New Hardware:

AUSM-B:

Software Features:

- PXM Redundancy

- Graceful upgrades (PXM, SMs). Minimum software release has to be 1.1.00 for graceful upgrade to work. Graceful upgrade cannot be used to upgrade from 1.0.00 to 1.1.00.

- CiscoView support for RPM. This feature introduces the capability of SNMP access to the RPM cards in a MGX 8850 shelf that is consistent with other service modules. It enables the CiscoView equipment management software to manage the RPM blades in the shelf.

- Environmental monitoring: Allows for periodic monitoring of the environmental variables such as temperature, fan speed and power supply voltage levels. When any readings beyond the recommended range are observed an alarm is generated. In this release, monitoring of temperature and power supply voltage is provided.

1. Hardware

MGX 8850 is a 45 Gbps backplane with 1.2 Gbps switching fabric for release 1.0.00. The same backplane is used with different switching fabric cards (1.2, 45 Gbps) to achieve scalability. MGX 8850 release 1.0.00 hardware components and their revisions that are supported are as follows;

Front card model #
Rev #
Back card model #
Rev #

MGX 8850 Chassis

A

   

MGX-DC power supply

MGX-AC1 power supply

MGX-AC2-2 power supply

PS-1200-AC power supply

A

A

A

A

   

MGX-SRM-3T3-B

A

MGX-BNC-3T3

A

PXM1

A

PXM-UI

A

PXM-1-2-T3E3

A

PXM-UI

MGX-BNC-2E3

MGX-BNC-2E3A

MGX-BNC-2T3

A

A

A

A

PXM-1-4-155

A

PXM-UI

MGX-MMF-4-155

MGX-SMFIR-4-155

MGX-SMFLR-4-155

A

A

A

A

PXM-1-1-622

A

PXM-UI

MGX-SMFIR-1-622

MGX-SMFLR-1-622

A

A

A

MGX-RPM-64M

A

MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E

MGX-MMF-FDDI

MGX-SMF-FDDI

MGX-MMF-FDDI/FD

MGX-SMF-FDDI/FD

A

A

A

A

A

A

A

MGX-RPM-128M

A

MGX-RJ45-FE

MGX-MMF-FE

MGX-RJ45-4E

MGX-MMF-FDDI

MGX-SMF-FDDI

MGX-MMF-FDDI/FD

MGX-SMF-FDDI/FD

A

A

A

A

A

A

A

AX-CESM-8E1

A

AX-SMB-8E1

AX-RJ48-8E1

AX-R-SMB-8E1

AX-R-RJ48-8E1

 

AX-CESM-8T1

A

AX-RJ48-8T1

AX-R-RJ48-8T1

 

MGX-AUSM-8E1/B

A

AX-SMB-8E1

AX-RJ48-8E1

AX-R-SMB-8E1

AX-R-RJ48-8E1

 

MGX-AUSM-8T1/B

A

AX-RJ48-8T1

AX-R-RJ48-8T1

 

AX-FRSM-8E1

AC

AX-SMB-8E1

AX-RJ48-8E1

AX-R-SMB-8E1

AX-R-RJ48-8E1

 

AX-FRSM-8E1-C

AC

AX-SMB-8E1

AX-RJ48-8E1

AX-R-SMB-8E1

AX-R-RJ48-8E1

 

AX-FRSM-8T1

AC

AX-RJ48-8T1

AX-R-RJ48-8T1

 

AX-FRSM-8T1-C

AC

AX-RJ48-8T1

AX-R-RJ48-8T1

 

MGX-FRSM-HS2

A

MGX-SCSCI2-2HSSI/B

A

MGX-FRSM-2CT3

A

MGX-BNC-2T3

A

MGX-FRSM-2T3E3

A

MGX-BNC-2E3

MGX-BNC-2E3A

A

A


Support for embedded Cisco IOS router (Router Processor Module - RPM)

The RPM is an embedded Cisco IOS router with integrated ATM Deluxe Port Adapter and Cell Bus Controller ASIC for internal connections to the backplane cell bus. A number of port adaptors (back cards) can be configured with the RPM front card (FDDI, Ethernet, Fast Ethernet).

3E Adapter

FE Adapter (UTP, MMF)

FDDI Adapter (full duplex, half duplex, SMF, MMF)

MGX 8220 Hardware not supported on Release 1.1.00 of the MGX 8850

The following cards are not supported in Release 1.1.00:

AX-FRSM-HS1

AX-SRM-T1E1

MGX 8220 Hardware that has been superseded on the MGX 8850 by MGX 8850-specific Hardware

AX-SRM-3T3-A and AX-BNC-3T3 card set

The MGX-SRM-3T3-B 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. This change allows the use of slots 9, 10, 25, and 26 for 1:n redundancy and BERT in the MGX 8850 chassis. Both the AX-SRM-3T3-A/AX-BNC-3T3 card set and the MGX-SRM-3T3-B/MGX-BNC-3T3 card set are supported on the MGX 8220.

AX-SCSI2-2HSSI

Superseded by the MGX-SCSCI2-2HSSI/B, which works with the MGX-FRSM-HS2 front card. A V.35 interface will be supported on the AX-FRSM-HS1 in future releases.

AX-IMATM

Superseded by MGX-AUSM-8T1/B and MGX-AUSM-8E1/B

AX-IMATM-B

Superseded by MGX-AUSM-8T1/B and MGX-AUSM-8E1/B

MGX 8220 Hardware that will not be supported on the MGX 8850

AX-FRASM-8T1

All MGX 8820 four port cards

AX-AUSM-8T1/A

AX-AUSM-8E1/A

3. Software Platform Features

1 MGX 8850 provides high speed native ATM interfaces which can be configured as ATM UNI ports or trunks

2 Redundancy

PXM core card redundancy is supported in this release.

3 Support for 1:N and 1:1 Service Module Redundancy, as indicated in the table below:

Front card model #
Redundancy supported

MGX-RPM-64M

No redundancy

MGX-RPM-128M

No redundancy

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

AX-FRSM-8E1

1:N redundancy

AX-FRSM-8E1-C

1:N redundancy

AX-FRSM-8T1

1:N redundancy

AX-FRSM-8T1-C

1:N redundancy

MGX-FRSM-HS2

1:1 redundancy

MGX-FRSM-2CT3

1:1 redundancy

MGX-FRSM-2T3E3

1:1 redundancy


4 Support for Bulk Distribution using SRM-3T3B card.

5 Service module and PXM upgrades

Features not supported in this release:

RPM 1:1 redundancy

RPM statistics

APS on PXM OC3 and OC12

FRSM-HS1-B

BERT on T1/E1 port cards

BERT on 2CT3 cards

Traffic management, policing, and multiple ports on PXM UNI

Coexistence as feeder and stand-alone

MPLS support (Tag edge router and tag edge controller)

Layer 2 support as an autoroute routing node

SRM T1E1

IGX/IPX endpoints with the MGX 8850

MGX 8220 Release 4.1.00 circuit emulation endpoints

CESM-T3/E3 service module

Major Network Management Features

CWM Connection Management

CiscoView support for equipment management

CLI support

Service MIB support

Connection Management for connections to RPM with associated CM GUI support.

Topology subsystem enhancements to support the MGX 8850 as a stand-alone switch.

Statistics

For more details refer to the CWM Release 9.2.02 release notes part number 78-6659-02

Connection Limits

1000 connections per card

4000 connections per shelf

SNMP MIB:

The SNMP MGX 8850 MIB is being provided with the delivery of Release 1.2.00 of the MGX 8850 software on CCO. The MIB is in standard ASN.1 format and is located in the ASCII text files MGX8800Mib.my file which is included in the same directory within CCO. These files may be compiled with most standards-based MIB compilers. For changes in this MIB from release 1.0.00 please refer to the MIB release notes on CCO.

Notes & Cautions

NODE RELATED

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 do not use this common boot code (release 2.0.xx, 3.0.xx, 4.0.xx of boot code) 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.

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:

tftp <ip address of the MGX 8220 shelf > 
bin 
put <boot filename> AXIS_SM_1_<slot#>.BOOT 

Now you must insure that tftp downloaded the appropriate boot code by verifying the flash checksums.

Login to the shelf.

cc <slot #>'
chkflash'

Verify that the two checksums are the same.

If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.


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 RMA'ed.

MGX 8850 MGX-FRSM-HS2, MGX-FRSM-2CT3, MGX-FRSM-2T3E3 need to have release 10.0.01 firmware for the runtime image and release 10.0.01 firmware for the backup boot image.

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

In addition to clearing all the 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 reconfigured using the cnfifip command. Refer to the entry on cnfifip in the Cisco MGX 8850 Command Reference publication on the documentation CD for syntax.

- All connections, ports and lines must be deleted before issuing the clrsmcnf command.

- The copychan command does not work on the MGX 8850

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

Do not install 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 at all with the shelf through the console ports. If after switchcc standby PXM loses the downlevel port then it is due to a downlevel Beta version of UIA backcard that were shipped during field-trial only. Upgrading the UIA back card to the latest version should fix this problem.

You can only configure an AUSM service module as the clock source. If you try to configure an FRSM-8E1/T1 as the clock source, the error message displays that the service module does not provide clock driving support, but the dspclksrc command shows FRSM-8T1/E1 even though it is the previous configured AUSM clock source (CSCdm38800)

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.

New LMI commands:

You must reboot your PXM after each modification with "bootChange" for it to take effect. Also make sure the subnet mask is 255.255.0.0

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

Configuration save and restore is only supported through the CLI (CWM does not support configuration save and restore).- 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 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 only supported for adjacent slots.

Statistics are not supported for the RPM

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 acctuator. When the card is reinserted the PXM automatically comes out of sleep mode.

Syntax of "addlink" command has changed as follows:

New Syntax:

Syntax: addlink <T3LineNum> <T1Slot> <NumberOfT1s> <TargetSlotNum>

<TargetSlotLineNum>

<T3LineNum> where = Slot.Line

Slot = 15,31

Line = 1 - 3

<T1Slot> where T1Slot = 1 - 28

<NumberOfT1s> where NumberOfT1s = 1-8

<TargetSlotNum> where TargetSlotNum = 1-6|11-14|17-22|27-30

<TargetSlotLineNum> where TargetSlotLineNum = 1-8

PAR command "cnfnwip" has been disabled in this release, please use "cnfifip" instead.

If you lose power, or remove the on-line PXM you lose the broadcast address. Use the "cnfifip" command to configure the broadcast address. To re-define your ATM address and IP Address that are in the same subnet, you have to change the ATM address to a temporary address not in the same subnet, then add back your IP Address with the original Broadcast address, then go back and correct your ATM address.

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

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.

RPM RELATED

Recommendations for Booting:

The current implementation provides the following options:

From PXM Disk

NetBoot (TFTP server)

Booting from PXM Disk is faster then NetBoot.

----------------------------------------------------------------------------------------------------------------------

Recommendations for saving RPM configuration

The current implementation provides the following options:

a. Save on flash / boot-flash.

b. Save on PXM Disk.

c. Save on network (TFTP server)

d. Save on RPM NVRAM (comes up faster; only for limited configuration size)

It is recommended to save the configuration on flash and on the PXM Disk, as well as on the network server. This ensures that the configuration can be restored; even in the case of multiple failures.

For example if an RPM card has problems, one can copy the configuration from either the PXM disk or from the network to new RPM card. In case of multiple hardware failures (both RPM and PXM cards have problems) one can copy the configuration from the network server.

----------------------------------------------------------------------------------------------------------------------

Replacing the existing RPM with a new card or a card with old configuration in flash:

The existing configuration (of the old card) can be restored on the newly inserted card by following the instructions given below:

1. Insert the new card into an unreserved empty slot. A previously used slot can be unreserved by giving the "clrsmcnf" command.

2. By default the ATM interface comes in "shut" mode. Enable the ATM interface of the new card by following commands in order:

config term

interface switch <slot #>/1

no shut

3. Copy the old RPM's configuration (from the PXM disk or the network server) to the new card's bootflash (For example copying from PXM disk: "copy c:<image name> bootflash:").

4. Configure the new card to use the configuration in its bootflash using the "boot config bootflash: <config-file-name>" command.

5. Save the changes using "write mem" command.

6. Insert the new card into the old slot.

Please note that in RPM context the "config save/restore" feature of the PXM only restores the PXM part of the RPM configuration/connections. The RPM part of the configuration should also be saved from RPM CLI through copy command (For example: "copy run c:<config-filename>" for saving to PXM Disk) for future restoration.

----------------------------------------------------------------------------------------------------------------------

RPM Connection Resynchronization:

The RPM Connection Re-sync process is supported in the 12.04T release. This feature checks for consistency between the RPM and PXM connection databases. ----------------------------------------------------------------------------------------------------------------------

Limitations

The MGX 8850 does not support CESM endpoints with MGX 8220 release 4.1 through CWM, but is supported through the CLI (CSCdm11835).

The Service MIB does not support resource partition.

BERT is only supported on FRSM-2T3 and FRSM 2E3 service modules.

SLIP is supported on the maintenance port, but there is no PPP support on the maintenance port.

No traffic management or policing on PXM UNI ports

For a feeder, only one port can be used as a uplink trunk interface. In a stand alone configuration, one port can be used as a user-side UNI, and one port can be used as a network-side UNI with no policing.

BIS messages are constantly being sent from BPX to various nodes - This affects the frequency of TFTP updates, which may affect CWM performance and/or CWM database consistency (CSCdm29396 - swsw 9.1.10)

Unable to provision virtual trunks in SWSW 9.1.10 (CSCdm12851)

Problems fixed in this release 1.1.00

Stand-alone Statistics collection does not work if the PXM is in slot 8 (CSCdm20017).

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 acctuator. When the card is reinserted the PXM automatically comes out of sleep mode.

In Release 1.0.00 Configuration Save and Restore works only for the same firmware image even if there are no database changes from one version to the other version. In release 1.1.00 Configuration Save and Restore can be done on different firmware images if the firmware images have compatible databases.

VPI range was limited to 0 to 255 on PXM UNI and NNI on the feeder ports in Release 1.0.00. There is no VPI range limit in Release 1.1.00. (CSCdk63920)

A flood of SNMP requests can cause SNMP and CLI to be unavailable for some time (CSCdm13663).

After a user adds PXM UNI channel, VCC with VCI=0, user cannot add any more VCCs with same (CSCdm14123)

Was unable to delete a VP connection for PXM UNI channels using CWM (CSCdm15120)

While executing "cc" command to a Service Module (SM) on a telnet session, the telnet session hangs, and the console of the active PXM card has Tlb load exception message. (CSCdm15150

Telnet session gets cut off without any error messages or obvious network problem (CSCdm15166)

When adding connections using scripts utilizing Conn-Proxy, without delay between two connection additions, and when there are line alarms at either endpoint, there is a probability that the CESM card may reboot. (CSCdk12363)

FRSM-2CT3 is dropping frames due to frame aborts detected by HDLC controller. (CSCdm13123)

Traffic on connection on FRSM-8T1E1 stopped after removal and insertion (CSCdm18521)

Cannot have more than one session on FRSM-VHS (CSCdk77924)

A channel is shown in alarm even though there is no line alarm and port alarm locally on the FRSM8p service module, and there is no remote alarm on the far end of the connection. (CSCdm14383)

Port statuses at service module site might be different with those at PXM and VSI controller site.(CSCdm15183)

A port was seen that had no alarm on FRSM8p, but "dspparifs" on PXM CLI shows the interface of this port in fail state. (CSCdm15620)

Attempt to configure the external clock source using the label 0.33 does not work. (CSCdm15669)

Some FRSM-8T1E1s don't come up when the MGX8850 is power cycled. (CSCdm16401)

Using script to add ports on FRSM8P Service Module card, in case a port addition fails, FRSM8 is not backing off properly and leave the port still added locally on the card even though the port is not added on PXM side and PAR (the interface corresponding to this port will not show up in "dspparifs" CLI on PXM, but "dspports" on SM shows the port added). (CSCdm03268)

Connections in alarm while lines are OK. (CSCdm10735)

Service module & the PXM reserve different bandwidth for the same connection.(CSCdk92115)

The card, after power recycle does not come up. It gets stuck in standby. (CSCdm10416)

When removing a service module or removing a line, VSI controller prints out "swerr 20208" sometimes. (CSCdm16902)

When an MGX 8850 shelf with CESM-8T1E1s is left running for over a day with Configuration Uploads going continuously, there is a possibility of allocated large buffers not getting released. (CSCdm17868)

The interface state (port state) is inconsistent between the VSI controller and the platform as well as that at service module. (CSCdm16033)

A tftp download of backboot displays an S-objlib_OBJ_UNAVAILABLE error (CSCdm16295)

While RPM is reloading after a card reset or as a result of card removal, PXM gets reset intermittently. (CSCdm15040)

CLI commands on a PXM hang after aborting a command using Ctrl-C. (CSCdm16726)

PXM reset when OC12 trunk back card was inserted. (CSCdm20010)

Broad band connection statistics fail when the PXM is in slot 8 and statistics are enabled (CSCdm20017)

Problems Fixed for RPM in 12.0.4T

These anomalies are fixed in IOS 12.0.4T. For generic IOS issues, refer to the 12.0.4T release notes.

- RPM in adjacent slots share single OC3 cell-bus bandwidth, which cause a 30% drop in throughput at line speed. It is recommended not to use RPM in adjacent slots at high input rate configurations (CSCdk93626).

- Only VCI zero is supported for VPI greater than zero, therefore VP connections are limited to one VC.

- Under certain unknown condition RPM may not get the MAC addresses from the PXM. The occurrence of this conditions is quite low. It is recommended to set up the MAC address manually when such condition is detected. (CSCdk53731).

IPC buffers exhaust after executing CC command around 70 times. This requires a reload of RPM to re-establish IPC connectivity to PXM. This condition does not cause any interruption of traffic (CSCdk89950).

- Running an extended ping from an IPC console connection may overload the IPC channel (CSCdk76558)

- Virtual template is not supported through SNMP MIB.

- "tstcon" command to RPM is not supported in this version (CSCdm00845)

- SNMP over IPC channel is not supported in this version, therefore CV application is not supported (CSCdk47301).

- Reported CRC error counts may not be correct in this version (CSCdk70267)

- Tstcon option on CMGUI for PXM-FR connection is not displayed (CSCdk71714)

Documentation

Refer to the MGX 8850 user documentation on the documentation CD.

The Cisco MGX 8850 Installation and Configuration includes installation and configuration instructions for the following service modules:

AX-FRSM-HS1

AX-AUSM-8T1

AX-AUSM-8E1

AX-CESM-T3E3

These modules are not supported in this release, therefore, do not execute the configuration examples provided in the documentation.

The Cisco MGX 8850 Command Reference includes documentation of the following commands in support of the APS feature:

addapsln 

cnfapsln

The APS feature is not supported in this release, therefore, do not execute these commands.

The Cisco MGX 8850 Command Reference also includes documentation of the commands that can be executed on the following modules:

AX-FRSM-HS1

AX-CESM-T3E3

These modules are not supported in this release, therefore, do not execute the features on the following commands which are either CESM-T3E3 or FRSM-HS1-specific. The affected command descriptions include:

addln  (for FRSM-HS1)

There are 40 commands that are supported on the CESM-T3E3. Refer to Table 1-3 in the Cisco MGX 8850 Command Reference for a list of these commands

Compatibility Notes

1. MGX 8850 Software Interoperability with other Products

MGX 8850 Platform Software: PXM 1.1.00

MGX 8220 Firmware: Rev: 4.1.00 (Refer to the MGX 8220 Release Notes)

Compatible Switch Software: SwSw 9.1.10 for BPX and BXM firmware - MBW (Refer to the SwSw 9.1.10 Release Notes)

Network Management Software: CWM 9.2.02 (Refer to the CWM 9.2.02 Release Notes)

Cisco View: CV 4.2 WAN CV 2.01 (Refer to the CWM 9.2.02 Release Notes)

2. Software Boot and Runtime Firmware Requirements

BOARD PAIR
BOOT CODE
Version
FIRMWARE
Version

PXM1

pxm_bkup_1.1.00.fw

1.1.00

pxm_1.1.00.fw

1.1.00

PXM-1-2-T3E3

pxm_bkup_1.1.00.fw

1.1.00

pxm_1.1.00.fw

1.1.00

PXM-1-4-155

pxm_bkup_1.1.00.fw

1.1.00

pxm_1.1.00.fw

1.1.00

PXM-1-1-622

pxm_bkup_1.1.00.fw

1.1.00

pxm_1.1.00.fw

1.1.00

AX-CESM-8E1

cesm_8t1e1_CE8_BT_1.0.01.fw

1.0.01

cesm_8t1e1_10.0.01.fw

10.0.01

AX-CESM-8T1

cesm_8t1e1_CE8_BT_1.0.01.fw

1.0.01

cesm_8t1e1_10.0.01.fw

10.0.01

AX-AUSM-8E1

aim_8t1e1_AU8_BT_1.0.01.fw

1.0.01

ausm_8t1e1_10.0.01.fw

10.0.01

AX-AUSM-8T1

ausm_8t1e1_AU8_BT_1.0.01.fw

1.0.01

ausm_8t1e1_10.0.01.fw

10.0.01

AX-FRSM-8E1

frsm_8t1e1_FR8_BT_1.0.01.fw

1.0.01

frsm_8t1e1_10.0.01.fw

10.0.01

AX-FRSM-8E1-C

frsm_8t1e1_FR8_BT_1.0.01.fw

1.0.01

frsm_8t1e1_10.0.01.fw

10.0.01

AX-FRSM-8T1

frsm_8t1e1_FR8_BT_1.0.01.fw

1.0.01

frsm_8t1e1_10.0.01.fw

10.0.01

AX-FRSM-8T1-C

frsm_8t1e1_FR8_BT_1.0.01.fw

1.0.01

frsm_8t1e1_10.0.01.fw

10.0.01

MGX-FRSM-HS2

frsm_vhs_VHS_BT_1.0.01.fw

1.0.01

frsm_vhs_10.0.01.fw

10.0.01

MGX-FRSM-2CT3

frsm_vhs_VHS_BT_1.0.01.fw

1.0.01

frsm_vhs_10.0.01.fw

10.0.01

MGX-FRSM-2T3E3

frsm_vhs_VHS_BT_1.0.01.fw

1.0.01

frsm_vhs_10.0.01.fw

10.0.01


3. RPM Boot and IOS Image

RPM BOARD

BOOT CODE

IOS IMAGE

MGX-RPM-64M

rpm-boot-mz.120-4.T1

rpm-js-mz.120-4.T1

MGX-RPM-128M

rpm-boot-mz.120-4.T1

rpm-js-mz.120-4.T1


Location of RPM Images on CCO:

On CCO (http://www.cisco.com) click on "Software Center" under "Service & Support". This brings you to the Service & Support page. Click on "Cisco IOS Software".

From the left bar select the "Special File Access" button. Supply your special access code (as given by your account manager) and click on the "execute" button. This brings you to the page where the RPM 120-4.T1 images are posted.

Special Installation and Upgrade Requirements

Existing customers should use the upgrade procedure on page 23 to upgrade from 1.0.00 to 1.1.00, for new customers the image will be preinstalled as 1.1.00 and they need to use PXM installation procedure to upgrade to future maintenance releases.

Single PXM Installation Procedure


Step 1 Download the 1.1.00 PXM runtime image to the PXM.

tftp <node_name or IP address> 
bin 
put pxm_1.1.00.fw POPEYE@PXM_ACTIVE.FW 
quit 

Step 2 Download the ComMat.dat file to the C:/ directory of the Active PXM. Use the tftp put command:

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

Step 3 Execute the install 1.1.00 command.

Step 4 Answer Yes to the question the install command will ask.

Installation Procedure For Redundant PXMs:


Step 1 Verify that one PXM is Active and the other Standby.

Step 2 Download the 1.1.00 PXM runtime image to the Active PXM.

Step 3 Download the ComMat.dat file to the C:/ directory of the Active PXM.

Step 4 On the Active PXM, do "install 1.1.00".

[The cards will reset at this point, and it is not determinate which card will become the Active and which will become the Standby.]

Step 5 After the Standby card is reset and successfully enters the hold state, on the Active PXM, do "newrev 1.1.00".

Step 6 After the Active PXM is reset and successfully enters the hold state, on the Active PXM, do "commit 1.1.00".

PXM Flash Download Procedure


Step 1 Download the PXM backup image to the PXM.

tftp <node_name or IP address> 
bin 
put pxm_bkup_<revision>.fw POPEYE@PXM.BT 
quit 

Step 2 While in the same directory that you downloaded the backup boot file to, execute the downloadflash command.

Service Module Firmware Download Procedure


Step 1 Download the selected revision of service module firmware into the service module in the selected slot.

tftp <node_name or IP address> 
bin 
put <revision>.fw POPEYE@PXM_SM_1_<slot #>.FW 
quit 

Step 2 While in the same directory that you downloaded the backup boot file to, execute the downloadflash command.


Note   Please consult your Support Representative before performing any software upgrade.


Service Module Installation/Upgrade and Flashdownload Requirements.

- MGX 8220 service modules (AX-FRSM-8T1/E1, AX-AUSM-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 2.0.xx, 3.0.xx, 4.0.xx of boot code 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 8820 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:

tftp <ip address of the MGX 8220 shelf > 
bin 
put <boot filename> AXIS_SM_1_<slot#>.BOOT 

Now you must insure that tftp downloaded the appropriate boot code by verifying the flash checksums.

Login to the shelf.

cc <slot #>'
chkflash'

Verify that the two checksums are the same.

If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.


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.


- MGX 8850 MGX-FRSM-HS2, MGX-FRSM-2CT3, MGX-FRSM-2T3E3 need to have release 10.0.01 firmware for the runtime image and release 10.0.01 firmware for the backup boot image.

-If you need to upgrade both flash and runtime image of MGX 8220 Release 4.0.xx service modules to release 10.0.01 to operate within the MGX 8850 chassis please follow the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration publication on the documentation CD.

PXM Software 1.0.00 to 1.1.00 Upgrade Procedure

If you have previously loaded 1.0.00Ei (or any later release) onto your shelf, you don't have to reformat your disk as explained below.

We have completed the disk changes required to attain enhancement in performance. Basically, the changes are twofold.

Introducing DMA. DMA delivers 2.5-3 times the throughput.

Reduction in file system size. This delivers 4 times the throughput we previously had. The file system size is now set to 800 Meg.

Following is the procedure to bring up the shelf with the current release:

FOR SINGLE PXM SYSTEMS:


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


To set the PXM address, use the bootChange command:

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

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

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

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

To set the shelf IP address:

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

The second argument is the shelf IP address.

The third argument is the subnet mask.

The fourth argument is the broadcast address.


Step 1 On the PXM, save the current configuration:

 node-prompt> saveallcnf

Step 2 Get the filename by listing the CNF directory:

        node-prompt> ll "C:/CNF"
          size          date       time       name
        --------       ------     ------    --------
             512    APR-08-1999  08:16:18   .                 <DIR>
             512    APR-08-1999  08:16:18   ..                <DIR>
             512    APR-09-1999  05:26:42   TMP               <DIR>
           45433    APR-09-1999  05:28:42   NODENAME_0409990528.zip  
           45433    APR-09-1999  05:28:42   NODENAME.zip      
        In the file system : 
            total space :  819200 K bytes
            free  space :  787787 K bytes

For this case, the filename is NODENAME_0409990528.zip. The last set of numbers is the date and time (04/09/99 05:28). If you have executed the saveallcnf command a number of times, there will be a number of files, pick the one with the correct timestamp.

Step 3 On the workstation, upload the saved configuration to the workstation:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> get CNF/NODENAME_0409990528.zip
        Received 45433 bytes in 0.4 seconds

Step 4 Download the new bootcode:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> put pxm_bkup_1.1.00FW POPEYE@PXM.BT
        Sent 642232 bytes in 6.3 seconds

The byte count above is just an example. It will be different for different images. Make sure that the boot is successfully downloaded. You should see a message like the following on the console:

        Program length = 642230
        Calculated checksum = 0x2a5a41f2 stored checksum = 0x2a5a41f2
        Fw checksum passed

Step 5 Burn the backup boot into flash by using the "downloadflash" command (you can only have the one backup boot file in the /FW directory):

        node-prompt> downloadflash
        writing pxm_bkup_1.1.00.fw to flash...
        Board recognized as a PXM1A board ... 
        Checksum size is 642230 ... 
        Erasing the flash .... 
        FLASH erase complete 
        Downloading C:/FW/pxm_bkup_1.1.00.fw into the flash ... 
        verifying flash contents ....  
        Flash ok .... 

Step 6 Reboot the shelf:

        node-prompt> resetsys
        Do you want to proceed (Yes/No)? yes

The shelf should boot into backup boot and display the VxWorks prompt "->".

Step 7 Format the disk:

        -> ataFormat
        IDE: format in progress. This takes a while  ........
        .................................
        Disk format complete. Reboot the system  ..... 
        value = 0 = 0x0

This will take a long time (~25 minutes), so be patient.

Step 8 Reboot the PXM:

        -> reboot

Step 9 On the workstation, download the PXM FW:

        unix-prompt> tftp pxm.ip.address
        tftp> bin
        tftp> put pxm_1.1.00.fw POPEYE@PXM.FW
        Sent 1982672 bytes in 18.3 seconds

Make sure that the transfer is successful, by looking at the message displayed on the PXM console after the transfer:

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

Step 10 Set the FW version to be booted:

        -> setPXMPrimary "1.1.00"

Step 11 Reset the PXM:

        -> reboot

Step 12 Download the saved configuration to the shelf:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> put NODENAME_0409990528.zip CNF/NODENAME_0409990528.zip
        Sent 45433 bytes in 0.4 seconds

Step 13 Download the SM firmware to the shelf:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tptp>put frsm_8t1e1_10.0.01.fw POPEYE@SM_1_0.FW
        Sent 1982672 bytes in 18.3 seconds

Make sure that the transfer is successful, by looking at the message displayed on the PXM console after the transfer:

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

Repeat for each SM type and for each slot specific fw.

Step 14 Restore the configuration:

node-prompt> restoreallcnf -fNODENAME_0409990528.zip
The saved FW version (1.0.00) is not same as the current FW version 
(1.1.00)
Do you want to proceed with the saved FW version (1.0.00)? no
Do you want to keep the current FW version (1.1.00)
(WARNING, the databases in these FW versions must be compatible or upgradeable 
for this to work)? yes
All current config will be replaced with the specified restored config and the 
shelf will be reset.
Do you want to proceed (Yes/No)? yes
Syncing ...... 
Flash download completed.

FOR REDUNDANT PXM SYSTEMS TO BE UPDATED ALL AT ONCE (ONE LONG OUTAGE - THIS IS NOT GRACEFUL)

If you have previously loaded 1.0.00Ei (or any later releases) onto your shelf, you don't have to reformat your disk as explained below and you can skip steps 1-10 and start from step 11.

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


Step 1 To set the PXM addresses, use the bootChange command:

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

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

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

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

To set the shelf IP address:

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

The second argument is the shelf IP address.

The third argument is the subnet mask.

The fourth argument is the broadcast address.

Step 2 On the active PXM, save the current configuration:

        node-prompt> saveallcnf

Step 3 Get the filename by listing the CNF directory:

        node-prompt> ll "C:/CNF"
          size          date       time       name
        --------       ------     ------    --------
             512    APR-08-1999  08:16:18   .                 <DIR>
             512    APR-08-1999  08:16:18   ..                <DIR>
             512    APR-09-1999  05:26:42   TMP               <DIR>
           45433    APR-09-1999  05:28:42   NODENAME_0409990528.zip  
           45433    APR-09-1999  05:28:42   NODENAME.zip      
        In the file system : 
            total space :  819200 K bytes
            free  space :  787787 K bytes

For this case, the filename is NODENAME_0409990528.zip. The last set of number is the date and time (04/09/99 05:28). If you have executed the saveallcnf a number of times, there will be a number of files, pick the one with the correct timestamp.

Step 4 On the workstation, upload the saved configuration to the workstation:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> get CNF/NODENAME_0409990528.zip
        Received 45433 bytes in 0.4 seconds

Step 5 Download the new bootcode from the workstation:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> put pxm_bkup_1.1.00.fw POPEYE@PXM.BT
        Sent 642232 bytes in 6.3 seconds

Make sure that the boot is successfully downloaded. You should see a message like the following on the console:

        Program length = 642230
        Calculated checksum = 0x2a5a41f2 stored checksum = 0x2a5a41f2
        Fw checksum passed

On the redundant PXMs, make sure that the boot is completely copied to the standby PXM. If you have a console connected to the standby PXM, you should see a message similar to the one on the active console.

If you do not have a console connected to the standby PXM, from the active PXM console cc to the standby PXM list the FW directory:

        node-prompt> cc standby-pxm-number
        (session redirected)
        node-prompt> ll "C:/FW"
          size          date       time       name
        --------       ------     ------    --------
             512    APR-08-1999  08:16:18   .                 <DIR>
             512    APR-08-1999  08:16:18   ..                <DIR>
         1982672    APR-08-1999  08:17:10   pxm_1.1.00.fw   
          818676    APR-08-1999  08:59:30   sm35.fw           
          642232    APR-09-1999  05:44:30   pxm_bkup_1.1.00.fw  
        In the file system : 
            total space :  819200 K bytes
            free  space :  787150 K bytes

Step 6 Burn the backup boot into flash by using the "downloadflash" command :

        node-prompt> downloadflash
        writing pxm_bkup_1.1.00.fw to flash...
        Board recognised as a PXM1A board ... 
        Checksum size is 642230 ... 
        Erasing the flash .... 
        FLASH erase complete 
        Downloading C:/FW/pxm_bkup_1.1.00.fw into the flash ... 
        verifying flash contents ....  
        Flash ok .... 

Repeat this on the standby PXM. Note that you can only have the one backup boot file in the /FW directory. Remove any old backup boot files by issuing the cd /FW command to move to the FW directory and issuing the rm command to remove the old files.

command

Step 7 Reboot the shelf:

        node-prompt> resetsys
        Do you want to proceed (Yes/No)? yes

You will need a console connection to both of the PXMs.

The shelf should boot into backup boot and display the VxWorks prompt "->".

Step 8 Format the disk:

        -> ataFormat
        IDE: format in progress. This takes a while  ........
        .................................
        Disk format complete. Reboot the system  ..... 
        value = 0 = 0x0

This will take a long time (~25 minutes), so be patient.

Step 9 Repeat Step 8 on the other PXM. The system may report unable to register standby. You can ignore this message and proceed to Step 10.

Step 10 Reboot the PXM:

        -> reboot

Step 11 On the workstation, download the PXM FW:

        unix-prompt> tftp pxm.ip.address
        tftp> bin
        tftp> put pxm_1.1.00.fw POPEYE@PXM.FW
        Sent 1982672 bytes in 18.3 seconds

Make sure that the transfer is successful, by looking at the message displayed on the PXM console after the transfer:

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

Step 12 Set the FW version to be booted:

        -> setPXMPrimary "1.1.00"

Step 13 Repeat steps 11 and 12 on the other PXM.

Step 14 Reset the PXM:

        -> reboot

Step 15 Repeat Step 14 on the other PXM.

Step 16 Download the saved configuration to the shelf:

        unix-prompt> tftp shelf.ip.address
        tftp> bin
        tftp> put NODENAME_0409990528.zip CNF/NODENAME_0409990528.zip
        Sent 45433 bytes in 0.4 seconds

Step 17 Download the SM firmware to the shelf:

unix-prompt> tftp shelf.ip.address
tftp> bin
tftp> put frms8et1_10.0.00.fw POPEYE@SM_1_0.FW
Sent 1982672 bytes in 18.3 seconds
Make sure that the transfer is successful, by looking at the message displayed 
on the PXM console after the transfer:
Program length = 1982672
Calculated checksum = 0xd9779bc6 stored checksum = 0xd9779bc6
Fw checksum passed

Repeat for each SM type and for each slot specific fw.

Step 18 Restore the configuration:

node-prompt> restoreallcnf -fNODENAME_0409990528.zip
The saved FW version (1.0.00) is not same as the current FW version (1.1.00)
Do you want to proceed with the saved FW version (1.0.00)? no
Do you want to keep the current FW version (1.1.00)
(WARNING, the databases in these FW versions must be
compatible or upgradeable for this to work)? yes
All current config will be replaced with the specified restored config and the 
shelf will be reset.
Do you want to proceed (Yes/No)? yes
Syncing ...... 
Flash download completed.

4. Service Module Upgrades

The following steps need to be followed for service module upgrade. Service module firmware images cannot be downloaded as specific versions in MGX 8850 Release 1.0.00 because only one image can be present on the disk at one instance. Hence the user cannot revert back during the installation process.


Step 1 Download the firmware image.

tftp <ip address of the MGX 8850 shelf > 
bin 
put frsm_<version>.fw POPEYE@SM_1_<slot#>.FW 

for a slot-specific image (in this example the service module is tied to slot 1),

or

tftp <ip address of the MGX 8850 shelf > 
bin 
put frsm_<version>.fw POPEYE@SM_1_0.BOOT 

for a slot-independent image,


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.

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.


Known Anomalies for Platform Software and Service Module Firmware

The following is the list of known anomalies in the MGX 8850, release 1.1.00 delivery. 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

CSCdk36727

Symptom:

Trap managers are not aged. If a trap manager is added, it has to be explicitly deleted.

Condition:

There are a maximum of 12 trap managers allowed. With aging, a trap manager that has not communicated with the agent for 30 minutes is aged out from the list. Without aging, if the maximum number of managers have already been added, newer managers will not be able to register for traps.

Workaround:

Delete the unwanted trap managers by executing the CLI command "deltrapmgr <IP>" from the PXM. This will create room for new trap managers.

CSCdk56888

Symptom:

Unexpected RAI alarms while configure DSX1 line in SF mode

Conditions:

DS1 line on FRSM-2CT3 goes into alarm(RAI) and comes out when the line is configured in SF(SuperFrame) mode and LMI is enabled on the one of the ports existing on this line.

Workaround:

When the line is operating in ESF mode this doesn't happen. Currently the work-around is change the framing mode to ESF using the "cnfln" command.

CSCdm05358

Symptom:

When modifying a particular protected memory address on CESM8p which causes CESM HW watchdog reset, PXM got reset or lost SAR functionality.

Description:

When this happens, CESM sent a huge amount of traffic onto the management connection which is supposed to be used for intercard communication activities such as polling.

This traffic causes the SAR to spend all its resources on doing the cleaning/flushing in ISR (interrupt service).

This address should never be modified using the shellConn 'modify' command. It was used unknowingly in debug/test process.

Workaround:

Don't try to modify this protected address in shellConn (m 0xb300060) (0xb300060 is ATMizer CPU address for SAR on CESM8P).

As a general guideline, shellConn commands like 'modify memory' should not be used by the customer.

CSCdm09225

Symptom:

The customer would like to have the ability to measure the processor consumption by process on the MGX 8850, the same way they can on the BPX.

Workaround:

There is a way to measure processor utilization using the shellConn command "spy".

If you go into shellConn and issue spyHelp it gives all the commands related to spy.

The way to start spy is:

spy [freq[,ticksPerSec]]

where freq is number of seconds between reports (default 5 seconds) and ticksPerSec is the number of samples taken per second (defaults to 100)

The way to stop spy is:

spyStop

CSCdk72991

Symptom:

FRSM-VHS takes several minutes to go active when inserted the first time or after clrallcnf.

Condition:

The delay is due to the creation time of the FRSM-VHS database on the disk. This delay is only introduced the first time the card is inserted or after clrallcnf.

Work around:

Wait for card to go active

CSCdm10722

Symptom/Condition:

The install, newrev and commit commands for service module upgrade (there is no concept of downgrade here, as there exits only one valid, service module image on the disk at a time), do not follow, the same state machine as PXM commands in the current release.

Hence, it is mandatory, that for service modules, these commands are given in the documented order, which is:

(1) install

(2) newrev

(3) commit

WARNING: If these, commands are not given in the above specified order, we can be in a situation where we can have two different images running on the primary/secondary combination. However, on the disk, there is only one valid image for the service modules.

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.

CSCdm19747

Conditions:

cnfrscprtn and change vpi range to: vpi min =0, vpi max =0

This will lead to deleting connections that vpi is not 0.

Symptoms:

swerr 20909, swerr 20182, swerr 21501, swerr 20320

Work Around:

If there are many connections on the feeder trunk. Don't change the vpi range to smaller value than the connections' vpi The cnfrscprtn should be blocked at the source if there are conns on the interface.

CSCdm29289

Symptom/Condition:

One of the slots on the node had a CESM-8E1 card with some connections. The connections, ports and lines on the CESM were deleted and it was replaced with an AUSM-8T1 card.

The AUSM card went to mismatch state. On trying to execute the clrsmcnf command the following error message was seen:

flyers4.1.7.PXM.a > clrsmcnf 20
Do you want to proceed (Yes/No)? Yes
Command Failed: Resources exist on card

Work Around:

1. Prior to removing the CESM card and plugging in AUSM card, execute the clrsmcnf command on the CESM card. This is to remove all the CESM configuration on the hard disk.

2. Remove the CESM card and replace it with the AUSM card. The AUSM card will come up ACTIVE and operational.

CSCdm30193

Symptom:

Happens on an MGX 8850 switch with two PXMs (Core Redundancy). If the Active PXM while syncing the databases to Standby, resets, then the Standby PXM goes to Fail State. The reset PXM comes up as Active and will show the other PXM slot as Empty.

Condition:

When database syncing is going on, if the Active PXM resets, the Standby will go to Fail State. The Active PXM comes back and since the FWREADY is deasserted for Standby (Standby went to Fail State and hence its FWREADY is deasserted), the Active PXM will not be able to detect the Standby PXM and hence it will show up as Empty.

Work Around:

The Standby PXM needs to pulled out and put back in.

CSCdk68401

Symptom:

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.

Conditions:

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.

Workaround:

Use the command line interface to add a port on DS0 slot 32 of a CESM-8E1 line.

CSCdk33756

Symptoms:

ShelfIntegrated alarm becoming Major or Minor either after switchcc or resetsys.

Conditions:

Update of ShelfIntegratedAlarm not triggered due to messages getting dropped or alarm state change not reported by SMs.

Work Around:

Invoke pmmUpdateShelfIntegratedAlarm from shellconn or execute resetsys.

CSCdk56888

Symptom:

Unexpected RAI alarms while configure DSX1 line in SF mode

Conditions:

DS1 line on FRSM-2CT3 goes into alarm(RAI) and comes out when the line is configured in SF(SuperFrame) mode and LMI is enabled on the one of the ports existing on this line.

Workaround:

When line operating in ESF mode this doesn't happen. Currently the workaround is to change the framing mode to ESF using the cnfln command.

CSCdm12929

Symptom:

FRSM-2CT3 card throughput drops as frame size drops below 144 octets.

Conditions:

Currently FRSM-2CT3 has some system limitations when the frame size is less than 144 bytes. We will improve this to some extent in the next release.

Workaround:

There is no work-around for this.

CSCdm33289

Symptom/Condition:

The user was running a script which was adding lines, ports, and connections and deleting them. There was also switchover CC involved. The specific sequence of actions is unknown. It is not certain if the switchover was invoked in the middle of any action mentioned above or during the idle state.

Symptom:

One connection, CESM-PXM UNI ended up deleted in CESM, but SPM still has some incomplete data structure. Since there is only one connection per port for the CESM, and the connection is in such state that can not be removed or readded, the port and its bandwidth become unusable.

Work Around: clrallcnf

CSCdm28961

Symptom:

PXM having wrong A-bit status

Conditions:

Unknown.

Workaround:

There is no work-around for this.

CSCdk71643

Symptom/Condition:

This is suppose to be an added feature that gives robust end to end connectivity with full recovery in cases of error. But unfortunately, with the current design it will take some extra effort and time to provide this. It will be part of future enhancement and may be available in the next release. Just a little note about why, any Traps sent to PAR are directed by LCN number which is not available without a complete end to end connection, which currently limits the generation of Traps for incomplete connections (after a stipulated timeout period).

For now, due to absence of these traps a little more responsibility goes to the end user who is creating end to end connections. It is important that if and when a connection is added or removed both Master and Slave end of the connection should be added or removed respectively. Only one side of a connection should not be removed to create a new connection with the other side. Hence creating and deleting connections under any circumstance is complete only with the creation and deletion of both end of the connections. Failure to do this can result in unneeded dangling connections.

CSCdm11712

Symptom:

ingress frame delays impacts RTD.

Conditions:

The behavior of the devices (HDLC controller etc.) and the way SAR schedules cells in FRSM-2CT3 is quite different from FRSM-8T1/E1. We will try to improve RTD in future release.

Workaround:

Currently there is no work-around for this.

CSCdm12929

Symptom:

FRSM-2CT3 card throughput drops as frame size drops below 144 octets.

Conditions:

Currently FRSM-2CT3 has some system limitations when the frame size is less than 144 bytes. We will improve this to some extent in the next release.

Word around:

There is no work-around for this.

CSCdm30544

Problem:

The major card integrated alarm due to inconsistent databases on the PXM and the SM does not get cleared.

Symptom:

Under rare situations, a configuration change on an SM will fail to make the necessary changes on the PXM. The SM will try to back-off the changes and this might fail also. This failure to undo the changes will result in the inconsistent databases card integrated alarm (which can be seen using the "dspcd" command).

Workaround:

There is no workaround to prevent this alarm condition from happening. However it is extremely rare that it will occur. This alarm indication does not disappear at all. There is no CLI command to clear the alarm indication either. The only way to get rid of the alarm indication is to reset the card.

CSCdm35575

Symptom:

Configuring the DS3 framing format on an FRSM-2CT3 to M13 does not permit the card to operate correctly with other devices using that framing format.

Workaround:

At this time, only c-bot framing appears to be working.

CSCdm15367

Symptom:

When modifying a particular protected memory address on CESM8p which causes CESM HW watchdog reset, PXM got reset or lost SAR functionality.

Description:

When this happens, CESM sent huge amount of malicious traffic onto management connection which is supposed to be used for intercard communication activities such as polling. This malicious traffic causes SAR busying doing the cleaning/flushing in ISR (interrupt service).

Workaround:

Don't try to modify this protected address.

CSCdk86638

Symptom:

When using CWM to add connections, if the connection addition request times out, subsequent addition of the same connection may fail as well, complaining that the connection already exists (even though it timed out).

Description:

This is caused by two factors:

1. CWM assumes that when time out, connections are not added on the switch on which the timeout occurs, and thereby only removes other segments of the timed out connection on other involved nodes.

2. On MGX switch, when CWM reports connection timeout, it does necessarily mean a timeout on the switch as CWM timeout may be caused, for example, by the network delay etc. from switch and CWM. The connection may actually be provisioned on the switch.

Workaround:

Don't use the same vpi/vci/dlci used by the timed out connections. This can be fixed by CWM to perform a retrieval to check if the connection is actually provisioned or not on the switch, after connection addition times out.

CSCdm30541

Symptom:

cnfrscprtn fails to configure given vci range.

Description:

Only one dimensional resource partitioning, either VPI or VCI resource partitioning is available. If resource partitioning is attempted for both VPI & VCI, only VPI partitioning will take affect (if possible). The VCIs will be given full range for every controller. The command will not return error. VCI partitioning is only possible if the port is configured with only ONE VPI value instead of a range.

Workaround:

To use VCI partitioning, configure only ONE VPI value instead of a range.

CSCdm34114

Symptom:

CWM does not recognize changed RPM passwords.

Description:

Adding or modifying a connection to an RPM fails if the RPM enable password differs from the password that Conn MGR has cached. Example: A connection to an RPM is configured, then the enable password is changed on the RPM -- any subsequent connection adds or changes fail because of a bad enable password.

Workaround:

Exit and restart Conn MGR. The next attempt to configure a connection will not have any usernames or passwords cached.

CSCdm86638

Symptom:

CMGUI complains local/remote endpoint exists, if previously AddCon fails.

Description:

When using CWM to add connections, if the connection addition request times out, subsequent addition of the same connection may fail as well, complaining that the connection already exists (even though it timed out). This is caused by two factors; 1. CWM assumes that when time out, connections are not added on the switch on which the timeout occurs, and thereby only removes other segments of the timed out connection on other involved nodes. 2. On MGX switch, when CWM reports connection timeout, it does necessarily mean a timeout on the switch as CWM timeout may be caused, for example, by the network delay etc. from switch and CWM. The connection may actually be provisioned on the switch.

Workaround:

Don't use the same vpi/vci/dlci used by the timed out connections.

CSCdm21269

Symptom:

When the ATM uplink is under congested condition (ATM cloud), it is observed that the receiving FRSM is not receiving frames with FECN bit set and the sending FRSM is not receiving frames with BECN bit set as expected, if the FR-ATM interworking mode is set to service interworking transparent mode on the FRSMs.

Description:

Under the same congestion condition, FECN and BECN bits are set correctly in FR-ATM network interworking mode resource partition even though it doesn't exist on the PXM and SM.

Workaround:

Use network interworking instead of service interworking transparent mode.

CSCdm32893

Symptom:

When modifying the bandwidth allocation (usually from a smaller percentage to a much bigger one) of a port with 'cnfport' command, it is not always possible to create more connections under that port.

Condition:

The problem usually occurs when the port is created with a small percentage of the line bandwidth allocation. cnfport CLI command does not actually change the bandwidth allocation due to the software bug.

Workaround:

When creating a port, specify large percent bandwidth or 100% bandwidth and don't reconfigure the port by changing the bandwidth allocation.

CSCdm34030

Symptom:

The standby PXM console is not enabled for use.

Conditions:

This is a problem when you have PXM1A boards in redundant mode.

Workaround:

You can use the "cc" command to switch to the standby PXM.

CSCdm32773

Symptom/Condition:

Adding connections through a conn proxy script. Card went to failed state after adding around 700 connections.

Workaround:

Reset the card

CSCdm21684

Symptom:

SMs are shown in failed state though physically they are active. This was observed for FRSM8p and FRSM-VHS in slot 5 and 6 and 1. (see 'Eng-note' for detail.)

Work around:

This is determined to be caused by a pair of malfunctioning PXM board. This bug will be closed or junked after hardware team determines the root cause of the PXM board problem.

CSCdm33419

Symptom:

1. Add a 3-segment connection with PXM UNI endpoints.

2. Modify the SCR on the PXM UNI side to a big number, big enough to exceed the available bandwidth on the feeder trunk side. Also turn on CAC override.

3. Execute the modification. SV+ will display a successful result. Although the modification is rejected because oversubscribe is not allowed on the feeder trunk side.

Condition:

As mentioned in the symptom above. Note that the problem does not occur if the feeder trunk have enough bandwidth for the modification. The change will go through successfully.

Work Around:

When modify the connection bandwidth (SCR in this case), even though SV+ displays the successful result, one should verify the connection parameters to confirm the change. This can also be done via CLI (dspcon, dspchan).

CSCdm33677

Symptom:

Not able to add ABR1 connection from PXMUNI to PXMUNI (3-segment) whenever the fdrtrunk has some of its bandwidth used-up due to other conns.

Condition:

Using SV+ to add ABR1 connection. The SCR field is default to the max port bandwidth and not editable (greyed out). If there is at least one other connection already added, the available bandwidth will be less than that of the port speed.The new connection addition will fail.

Workaround:

Use CLI to add connection (addcon) then modify the SCR to the desired value (within what is available) via cnfupcabr (another CLI command).

CSCdm35298

Symptom:

While using a script to do stress switchcc test, there is a one time occurrence where it was found that the original active card did not come back as standby, but went to fail state.

Description:

This is likely caused by the script performing switchcc function before it comes back as active/standby.

Workaround:

when doing a manual switch, make sure that core card redundancy is established first.

CSCdm35352

Symptom:

The problem is related to the PVC's traffic parameters. We are still investigating what the PCR, average, and burst values should be set to for VBR connection. This values are related to nature of the traffic which is sent to the RPM.

Workaround:

This problem goes away when a larger average rate is used or PVCs are configured as UBR (average and burst is set to 0).

CSCdm23426

Symptom:

Config change trap carries the port resource partition row status as ADD while deleting the resource partition.

Conditions:

Wrong status will be sent with all resource partition DEL traps.

Workaround:

Currently there is no work around to avoid database inconsistency between SV+ and SM. This bug will be fixed in the next release.

CSCdm37454

Symptom/Condition:

Another observation, that was noted while debugging this bug, was that, when a different card type is inserted in the original primary slot, it goes into Mismatch state, which is the correct behavior. Now, this state is shown both by dspcds as well as dspred, command that is output of PMM and RED modules. However, RED module, keeps knowledge of old card type (the original card type in primary slot), which is also, correct, because redundancy has been configured for this slot. However, the problem, is that when you reset, the secondary, this Mismatch card also, gets reset, which is not expected. It should not be affected.

Workaround:

Pull, out this card, which is of different type, and insert back,the original primary card. It goes back into standby state, since the secondary is covering it. Now, redundancy is in stable state.

CSCdm27489

Symptom/Condition:

When the connection is deleted, the trap does not go to SV+.

Need to investigate this further to verify it.

CSCdm28075

Symptom:

1)added a ubr.2 dax connection on pxm (between port1 and port2) by sv+ showing for bbchanGcra2Action and scrPolicing in the following manner.

bbChanGcra2Action : No Action

bbChanUpcSCRPolicing : OFF

2)added ubr.2 connection by CLI commands.

showing for bbchanGcra2Action and scrPolicing in the following manner.

bbChanGcra2Action : Tag Cells

bbChanUpcSCRPolicing : CLP0

options shown in 2) is the correct.

Description:

UBR.2 is the policing type for UBR traffic where all cells from this UBR connection will be tagged.

Workaround:

This bug is (FCS3 bug) is fixed and will be available in the next release (1.2) Note: PXM-UNI UPC in general is not available in 1.1 release.

CSCdm34047

Symptom:

If "cnfcon" command is given with the CIR value of less than 8 and greater than zero then the command is never completed and later on one cannot do any modifications, display, etc.

Conditions:

Happens with the CIR value of 1 to 8.

Workaround:

Currently there is no workaround for this.

CSCdm22510

We are testing the performance penalty of adding the Traps. We are doing some testing and we will release this ASAP.

CSCdm34076

Symptom:

"dspservrate" shows IR as 0 cells/ second for some channels.

Workaround:

Currently there is no workaround for this problem.

CSCdm37114

Symptom:

restoreallcnf does not restore the saved config.

Conditions:

Occurs when restoring a configuration taken from another physical shelf. The card the restoreallcnf was done on will not become active but the other card will which contains the previous configuration.

Workaround:

Before issuing the restoreallcnf commmand do the following:

cc <standbyCard>

shellconn

dbmClrAllCnf

cc <active>

restoreallcnf -f<config.zip>

Further Problem Description:

Problem occurs because the restored config has a different shelf serial number in the saved bram image. When this value is restored then the shelf management software determines that this PXM was not in this shelf before and the other card was in this shelf and therefore the other card should be the active card and it initiates a switch of mastership to the other card. As a result the config on the other card is used rather than the restored config.

CSCdm36674

Symptom:

Connection addition fails for VP connection from CWM. This is easy to simulate.

Workaround:

The workaround is to add connections from CLI.VP con. addition succeeds from CLI. In case the VPID is out of range, increase the range using cnfrscprtn.

CSCdm38833

Symptom:

At low frequecies, the jitter characteristics does not fully comply with the standards.

This is because the receive side jitter is not currently enabled in the firmware.This should be fixed in the next firmware release.

CSCdm36595

Symptom:

Sometimes the channels satrt sending AIS cells on to the port. This problem is not reproducible.

Workaround:

Tearing off the entire connection and re-adding removes this problem. Before adding a configuration, do a clrsmcnf and start fresh. This would remove any stale configuration/database from the card.

CSCdm29249

Symptom:

This problem happens sometimes after a resetsys. Some AUSM cards get stuck in cardInit state.

Workaround:

The workaround is to reset the card again and it comes up active.

CSCdm17478

Symptom:

This bug is a cell spacing/rate issue of the traffic being pumped. It's under analysis still.

Workaround:

The work around is to increase the IBS to 100 so that no drops are seen.


Known Anomalies for RPM

These RPM anomalies are tied to its function with the MGX8850. For generic IOS issues, refer to the 12.0.4T release notes.

Under heavy load conditions from multiple sources, RPM performance may degrade (CSCdk91818)

Some RPMs may not boot when more than 8 RPMs are booting simultaneously from the PXM hard disk (CSCdm14987)

UBR connection for RPM is not supported from CWM, even though the CLI can support it

Obtaining Service and Support

For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.


Note   If you purchased your product from a reseller, you can access Cisco Connection On-line (CCO) as a guest. CCO is Cisco Systems' primary, real-time support channel. Your reseller offers programs that include direct access to CCO's services.


For service and support for a product purchased directly from Cisco, use CCO.

Cisco Connection On-line

Cisco Connection On-line (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

WWW:  http://www.cisco.com

WWW:  http://www-europe.cisco.com

WWW:  http://www-china.cisco.com

Telnet:  cco.cisco.com

Modem:  From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.


Note   If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.


78-6744-02