1.1.12 Version Software Release Notes
Cisco WAN SES Feeder for IGX Software

A minimum of two and up to four IP addresses are needed to be configured for SES feeder for IGX (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.

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 1.35. Do not use 0.33 or 1.33

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.1.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.1.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 the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.

The SES feeder for IGX 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.

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 SES feeder for IGX requires a minimum of one power supply to support the power requirement for 5 cards.

	0-5 cards	6-10 cards	11 and above
Single Line Cord (N+1):	1	1	2

This is based on an estimated worst case power requirement of 150W 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.

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

Limitations

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

Compatibility Notes

1. SES Feeder for IGX Software Interoperability with other Products

SES feeder for IGX Platform Software: PXM 1.1.12

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

Compatible Switch Software: SwSw 9.2.23 for IGX and UXM firmware - ABE (Refer to the SwSw 9.2.23 Release Notes)

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

Cisco View: CV 4.2 WAN CV 2.04
(Refer to the CWM 9.2.05 Release Notes)

2. Software Boot and Runtime Firmware Requirements

Board Pair	Boot Code	Version	Firmware	Tested Version	Minimum Version
SES-PXM	pxm_sc_bkup_1.1.12.fw	1.1.12	pxm_sc_1.1.12.fw	1.1.12	1.1.11
SES-PXM-4-155	pxm_sc_bkup_1.1.12.fw	1.1.12	pxm_sc_1.1.12.fw	1.1.12	1.1.11
AX-CESM-8E1	cesm_8t1e1_CE8_BT_1.0.01.fw	1.0.01	cesm_8t1e1_10.0.05.fw	10.0.05	10.0.04
AX-CESM-8T1	cesm_8t1e1_CE8_BT_1.0.01.fw	1.0.01	cesm_8t1e1_10.0.05.fw	10.0.05	10.0.04
MGX-AUSM-8E1/B	ausm_8t1e1_AU8_BT_1.0.01.fw	1.0.01	ausm_8t1e1_10.0.05.fw	10.0.05	10.0.04
MGX-AUSM-8T1/B	ausm_8t1e1_AU8_BT_1.0.01.fw	1.0.01	ausm_8t1e1_10.0.05.fw	10.0.05	10.0.04
AX-FRSM-8E1	frsm_8t1e1_FR8_BT_1.0.01.fw	1.0.01	frsm_8t1e1_10.0.05.fw	10.0.05	10.0.04
AX-FRSM-8E1-C	frsm_8t1e1_FR8_BT_1.0.01.fw	1.0.01	frsm_8t1e1_10.0.05.fw	10.0.05	10.0.04
AX-FRSM-8T1	frsm_8t1e1_FR8_BT_1.0.01.fw	1.0.01	frsm_8t1e1_10.0.05.fw	10.0.05	10.0.04
AX-FRSM-8T1-C	frsm_8t1e1_FR8_BT_1.0.01.fw	1.0.01	frsm_8t1e1_10.0.05.fw	10.0.05	10.0.04
MGX-FRSM-HS2	frsm_vhs_VHS_BT_1.0.01.fw	1.0.01	frsm_vhs_10.0.05.fw	10.0.05	10.0.04
MGX-FRSM-2CT3	frsm_vhs_VHS_BT_1.0.01.fw	1.0.01	frsm_vhs_10.0.05.fw	10.0.05	10.0.04
MGX-FRSM-2T3E3	frsm_vhs_VHS_BT_1.0.01.fw	1.0.01	frsm_vhs_10.0.05.fw	10.0.05	10.0.04

Special Installation Requirements

For this release the image will be pre installed as 1.1.12. All customers will only need to use these PXM installation procedures to upgrade to future maintenance releases.

Single PXM Installation Procedure

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

tftp <node_name or IP address> 
bin 
put pxm_sc_1.1.12.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

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

cp /FW
quit 
 

Step 4 Execute the install 1.1.12 command.

Step 5 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.12 PXM runtime image to the Active PXM.

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

Step 4 Copy the ComMat.dat file to the C:/FW directory of the Active PXM.

Step 5 On the Active PXM, execute the command "install 1.1.12".

[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 6 After the Standby card is reset and successfully enters the hold state, on the Active PXM, execute the command "newrev 1.1.12".

Step 7 After the Active PXM is reset and successfully enters the hold state, on the Active PXM, execute the command "commit 1.1.12".

PXM Flash Download Procedure

Step 1 Download the PXM backup image to the PXM.

tftp <node_name or IP address> 
bin 
put pxm_sc_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.

or

While in the same directory that you downloaded the backup boot file to, execute the command install bt 1.1.12.

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

Known Anomalies for Platform Software and Service Module Firmware

The following is the list of known anomalies in the SES feeder for IGX, release 1.1.12 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
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.
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 not necessarily mean a timeout on the switch. The 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.
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.
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.
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.
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.
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.
CSCdm22510	Symptom: Connection traps are not sent out when receiving A bit update from CPE. Conditions: The end result of this is that CWM will not be notified about the channel status change (failure or normal), neither will PXM/PAR. The remote end is notified via in band OAM. This applies to all service modules. Workaround: No Workaround
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 CWM and the service module.
CSCdm28951	Symptom: PXM having wrong A-bit status Conditions: Unknown. Workaround: There is no work-around for this.
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.
CSCdm33677	Symptom: Not able to add ABR1 connection from PXMUNI to PXMUNI (3-segment) whenever the feeder trunk has some of its bandwidth used up due to other connections. 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).
CSCdm40113	Symptom: It takes over 20 minutes for the FRSM-2CT3 cards to go active after a clrallcnf command has been issued. Conditions: Occurs when there are several FRSM-2CT3s in the shelf along with other service modules. Workaround: None. Wait for cards to go active. Further Problem Description: Creation of default service module config takes a long time and is processed one service module at a time. Subsequently, all the other SM wait to go active until the default config upload for all the service modules are done.
CSCdm44173	Symptom: Negative test failure. Changing the DC type results in connection being lost. Conditions: Changing the daughter card type (e.g oc3 to t3 or vice-versa) results in the PXM connections to be lost. This is due to the restore failure on a different physical interface type. Once the type of the daughter card is changed, the line driver will not add the line due to a different card type. However, the higher modules (PAR, VSI) etc. must have a mechanism in case of a restore failure and the should not result in connection deletion. Workaround: There is currently no workaround for this.
CSCdm44523	Symptom: bootChange inputs must include host name, or inet on ethernet field will go into the host name and file name fields as shown below -> bootChange '.' = clear field; '-' = go to previous field; ^D = quit boot device : lnPci processor number : 0 host name : e=172.16.156.29 file name : ffffff00 inet on ethernet (e) : inet on backplane (b): host inet (h) : gateway inet (g) : 172.16.156.1 user (u) : ftp password (pw) (blank = use rsh): flags (f) : 0x0 target name (tn) : startup script (s) : other (o) : Conditions: Occurs when executing the bootChange command, and nothing is entered in the host name field Workaround: Be sure to put something into the host name field, and this problem will not be seen
CSCdm45141	Symptom: Switchcc displays ssiFrameXmt failed and VSI master: invalid sw clock info pg Condition: The ssiXmtFrame failure was caused by SCM transmitting on GLCN=0, which is reserved. This is due to scmSwitch including slot 31 and slot 32 which are not mapped in SCM master. switchcc on PXM displays the following message in the PXM log: 1. ssiFrameXmt failed, error status -1 - 31 dropped 2. Vsi master: invalid sw clock info pg ; 2, 3, -2104681808 - 1 dropped 05/27/1999-06:16:13 07 PAR:Vsi PAR-7-VSIM_DEBUG Vsi master: invalid sw clock info pg ; 2, 3, -2104681808 - 1 dropped 05/27/1999-06:16:10 07 PAR:Vsi PAR-7-VSIM_DEBUG Vsi master: invalid sw clock info pg ; 2, 3, -2104681808 Workaround: No Workaround
CSCdm46245	Symptom: LED alarm light displays but dspalms shows no alarms. Condition: This intermittent condition occurs where Major Alarm red LED light displays while there is no actual alarm(s). CLI command "dspcds" shows Major shelfIntegratedAlarm, but dspcd (on service module) or dspalms shows all clear. This problem/condition is under investigation. Workaround: None.
CSCdm46394	Symptom: SYSTEM ERROR 20208 occurred during SM images upgrading to 10.0.02_01Jun99_1 Condition: This is a one time occurrence. The following is observed: ################################### ###### SYSTEM ERROR 20208 1 1179649 1 1179649 ################################### Description: The above error indicates that PAR is receiving bulk interface trap before the interfaces known to PAR, so PAR is logging the bad interface system error. This is a rare race condition. Subsequently when the individual port trap comes, the interface will be created in PAR properly. Workaround: No workaround. This error is not causing any problem as the port state will be updated correctly subsequently by the individual port trap.
CSCdm47203	Symptoms: In rare cases, adding huge amount of connections may cause FRSM-VHS SMs to slow down on "cc" responses. Conditions: The FRSM-VHS SMs may show warning messages on the console reporting "no more SCM buffers" or "no more session available". In some cases, the FRSM-VHS just simply not responding, or very slow on the console. Workaround: Increase timeout value for the "cc" command: > shellConn -> cliCcTimeout = 60 (Or any other value greater than 16 (default, in seconds). . Reset the service module. . There will be a fix to increase number of SCM buffers for FRSM-VHS service modules.
CSCdm49090	Symptoms: FRSM-VHS card fails to go to Active state during the upgrade process. It also fails to log any message. Conditions: This occurs when FRSM-VHS card has 16 MB DRAM and the firmware upgrade process (to firmware supporting 2000/4000 connections) is done. Work Around: User has to upgrade the hardware from 16MB to 32MB DRAM.
CSCdm49862	Symptom: dspln fails, returning "undefined symbol" mgx1.1.3.VHS2E3.a > dspln 1 undefined symbol: dspln mgx1.1.3.VHS2E3.a > dsp Unknown Command : dsp The possibilities are : dspalm dspalmcnf dspalmcnt dspalms dspbufoverflow dspcd dspcderrs dspcdprtntype dspcdrscprtn dspchan dspchancnt dspchanmap dspchans dspchstats dspcon dspcons dspds3ln dspds3lns dspdsx3bert dspegrq dspegrqs dspfeature dspfst dsplcn dspln dsplns dspmaptbl dspmsgcnt dspport dspportcnt dspportrscprtn dspports dspportstats dspsarcnt dspsarcnts dspservrate dspslftst dspslftsttbl dspstatparms dspsvcrange dsptaskinfo dsptotals dspusedlnmap mgx1.1.3.VHS2E3.a > version ***** Cisco System. AXIS FRSM-VHS Card ***** Firmware Version = 10.0.01 Backup Boot version = 5.0.00_15Dec98 VxWorks (for CISCO) version 5.3.1. Kernel: WIND version 2.5. Made on Sat May 8 00:43:44 PDT 1999. Workaround: No workaround
CSCdm51382	Symptom: FRSM-card takes about 1 minute to report A=0 to CPE, when line goes into alarm. Conditions: The conditions when this will occur is unknown. Still investigating the problem. Workaround: There is no workaround.
CSCdm51406	Symptom: The remote end card does not receive any OAM cells. Conditions: This happens when the local end card continuously sends OAM cells over a long period of time. Work Around: The local end card has to be reset so that it will start transmitting OAM cells.
CSCdm52380	Symptom: After an ungraceful upgrade, the PXMs end up in boot state. Conditions: An ungraceful upgrade using setPXMPrimary is done. Workaround: Reset the PXMs after the problem occurs.
CSCdm52590	Symptom: This occurs when a PXM is reset during an upgrade/downgrade operation (other than the reset performed as part of the operation). Work Around: Nothing, the PXM eventually gets to the correct state. It just takes a while.
CSCdm54916	Symptom: cesm-t1 with UNI connections start showing AIS-OAM cell incrementing. This can be seen using dspchancnt. However, no traffic loss has been observed because of these AIS cell increment. Condition: This problem is intermittent. Work Around: There is currently no work around for this.
CSCdm56094	Symptom The far end device can not be put into a loopback using the "Far End Inband Loopback" or the "Far End ESF Loopback" options under the "DEVICE TO LOOP" menu in the "cnfbert" command. If these options are chosen as part of a BERT pattern test, then the test will not be configured as it will fail to sync the pattern. Condition The inband and ESF loopbacks are activated/de-activated by transmitting the loopback codes for the minimum number of seconds specified by the ANSI T1.403 specification. However, due to variations in the way time is measured by the AUSM and the far-end devices, some devices do not detect the code for the desired number of seconds and hence they do not activate/deactivate the loopback. Workaround This problem may not be seen on all (far-end) devices. If it is seen, then there is no workaround other than trying to repeat the test configuration till it is successful.
CSCdm57683	Symptom: The dsplns command will display a line as disabled, but you cannot do an addln. Conditions: User runs the following sequence of commands: saveallcnf restoreallcnf install newrev commit Workaround: Do not execute the restoreallcnf command before executing the install command.
CSCdm57795	Symptom: Illegal LCN error message Conditions: When performing a switchcc, the following error popped up repeatedly. This was observed 3-4 times during DevTest. rmLcnBlkGet:illegal lcn number:lcn = 0 if = 0x 0 max_lcn = 4112 firstDataLcn = 16 rmLcnBlkGet:illegal lcn number:lcn = 0 if = 0x 0 max_lcn = 4112 firstDataLcn = 16 rmLcnBlkGet:illegal lcn number:lcn = 0 if = 0x 0 max_lcn = 4112 firstDataLcn = 16 rmLcnBlkGet:illegal lcn number:lcn = 0 if = 0x 0 max_lcn = 4112 firstDataLcn = 16 Description: This error message indicates that a connection with an illegal LCN (in this case it is LCN=0) is being resynced. It is found that this is not causing any problem on the switchcc, but may delay the the standby PXM up to 1 minute to go to active. Workaround: No workaround.
CSCdp03640	Symptom: The dspshelf command shows fans for the SES feeder for IGX that are not an option for the SES feeder for IGX. Workaround: No workaround.
CSCdp27092	Symptom: The SES feeder for IGX does not support the 42 MHz clock on the cell bus. The cnfcbclk, dspcbclk, xcnfcbclk, xdspcbclk commands do not work if executed on the SES feeder for IGX platform. This is due to the fact that the cell bus mapping to slot assignment is not done correctly for the SES feeder for IGX platform. Workaround: No workaround. Use the 21 MHz clock.

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.

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.

Posted: Mon Dec 20 14:24:55 PST 1999
Copyright 1989-1999©Cisco Systems Inc.