cc/td/doc/product/lan/cat3ks
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents


2.1(2) Software Release Note


2.1(2) Software Release Note

The 2.1(2) software release supports the existing Catalyst 3000 series and CPW1601 switches, and supports the following features:

Important. Read the first two pages of this document before upgrading to the 2.1(2) version of software.

Critical 2.1(2) Software Upgrading Instructions

Caution If you are upgrading an existing system which is running a pre-2.0 software release, you MUST upgrade the bootcode first. If you do not, the system will not boot when restarted.

Memory Limitations

CPW 1601 and Catalyst 3000 series switches must have 8 Megabytes of RAM in order to run software release 2.0 or higher.

System Limitations

The following is a list of certain system configuration limitations when using software release 2.0 or higher.

Configuration Notes

NMS Applications

There is no support for the LES, BUS and LECS MIBs in software release 2.1(2). CiscoWorks version 1.2 does offer support for the majority of the features in this release.

Known Anomalies

The following are known conditions in this version of the software release. It is not known at this time whether these conditions will be fixed in the next release of software.

LECS Timeout Warning Message (CSCdi80313)

The message "LECS warning: interface KAS ATM Interface( x ):ILMI timeout getting LECS addresses" may be generated several times under certain conditions on the console of a Catalyst 3x00 switch configured as a LECS. This message is cosmetic and does not indicate any sort of functional problem with the LECS or any other component of your ATM network.

Port Statistics Menu Overwriting Other Screens (CSCdi71685)

After exiting the Port Statistics menu, the screen may still refresh itself when the switch is under heavy traffic. To solve this problem, re-enter the menu and exit it again.

Running UNI 3.1 with an LS1010 (Reference CSCdj00359)

Software version 11.1(9), or higher, is required in an LS1010 in order to run UNI 3.1 with the LS1010.

Corrected Anomalies

The following conditions have been corrected since this version of the software release.

Remote Console Restriction For Router Configuration Screen (CSCdi70791)

In Stack configurations composed of a mix of Catalyst 3000 and 3200 switches, Some of the configuration parameters for an installed router card may not be modifiable from a remote console port in the Stack. The work around for this problem is to use a local console connection when it necessary to modify the configuration of a router card.

WS-X3002 Module Diagnostic LED Turned Off (CSCdi73577)

The diagnostic LED on the WS-X3002 four port 10BaseT module is turned off before the system powerup diagnostic test for this module is actually ran. This is cosmetic in nature and does not affect the effectivity of the diagnostic test.

Using Escape Key To Clear Console Message May Cancel Download (CSCdi80377)

If a console informational warning message appears while a TFTP download is in progress, pressing the escape key several times to clear the console warning may result in the cancellation of the TFTP download also. If a informational warning message does appear while a TFTP download is in progress, wait until you are sure the download is complete before pressing escape to clear the message. If you are not sure whether the download is complete, Wait 10 minutes or so to allow ample time for the download to complete before pressing escape to clear the message.

Learn And Lock Addresses And Their Deletion From Address Tables (CSCdi76624)

With the Learn And Lock feature, if an address is learned for a specific port, moving this address to another port would result in a communications failure. Learn And Lock does not allow an address to be moved from one port to another without clearing the address from the previous port (see the Learn and Lock section in the accompanying 2.1(2) Configuration Notes for more information).

SNMP Queries of VLAN Statistics

VLAN Statistics have not been implemented. SNMP queries on VLAN Statistics will return zero.

Corrected Console Conditions:

CSCdi93268 console shows the local/remote telnet ports as negative numbers

CSCdi87901 WS-X3013 expansion module: Indicates full duplex on port config menu

CSCdi93137 Lane config menus can be accessed from console/telnet @ same time

CSCdi69578 VCCs used for signalling reports as CD-?? in ATM channel statistics

CSCdj03158 display the boot image version

CSCdi83924 EnhanceReq for adding LEC uptime counter to LANE client screen

Corrected ATM Conditions:

CSCdj08257 High Ping Failure Rate Between Cat3k and FORE ATM NIC

CSCdi70598 LES/LECS connect problem when using an A100 switch

CSCdi81399 ATM clients change state to down

CSCdj03255 C3k LANE Svr Crash: STP:CPU BUFF TO NET BUF- NO MORE MEM

CSCdi80952 AM-- Moderate problem with LEC creation on one-trunk system

CSCdi87974 default LEC does not do shutdown completely

CSCdi80560 WARNING:eps_send:No network buffer available

CSCdj05733 Switching between ATM module and 100 BaseT port is broken

CSCdj06443 incorrect POE set in ATM firmware processing BI resp

CSCdj05138 ATM config menu busy after the LECS sub-menu is accessed.

CSCdi79694 Bring up ELAN w/ no local ports if IP interface is up

CSCdi83384 ATM interface name should be changed

Corrected ILMI conditions:

CSCdj02361 Invalid data on signalling/ILMI channels

Corrected IP Conditions:

CSCdj04617 Enhancement request-- Please set default IP state as disabled

CSCdi92434 IP semaphore grabbed and not released in certain situations

Corrected CDP Conditions:

CSCdj02742 Cat3k send CDP packets to Cat5k even when port is disabled

CSCdi88712 CDP/VTP should use port MAC address as source address

Other Corrected Conditions:

CSCdi66080 CPA ASIC appears to lock up under certain conditions

CSCdj00811 TRUNKING PROBLEM BETWEEN CAT5K AND CAT3K2

CSCdi89994 ciscoEsVLANInfoTable does not accept sets..

CSCdi91073 snmp poll of dot3 stats returns bogus numbers for FE links

CSCdj04444 Initial stack is being overrun by CheckFileSystemIntegrity().

CSCdi84347 Interface mib IfEntryType returns other for 10BaseT ports

CSCdi84350 CiscoES-StackPortEntry mib returns incorrect value on Cat3100

CSCdi84712 CiscoEsStackSwitchProbe mib rejects set the Probe to 0.

CSCdi82389 Cat 3K VTP packets contain byte-swapped STP types

CSCdi84764 Enabling ports after rebooting does not work

CSCdi89953 SNMP Trap Receiver VLANs only supports 64 VLANs

Upgrading an Existing System


Note The following sections refer to upgrading an existing configured system only. Ignore the following sections if you are upgrading the software on a system which is already running software release 2.0.

Preserving Existing VLAN/Domains in a VTP Configuration

If you are concerned with preserving your existing VLAN/Domain configuration in a VTP environment, review the section "Preserving a VTP Configuration" at the end of this document.

Downloading the 2.1(2) Image to an Existing System

If you download the 2.1(2) image to an existing system without first upgrading the bootcode, the system will fail to boot when you reset the box. All new boxes shipping with 2.1(2) will have the new bootcode; the problem applies only to boxes being upgraded in the field.

To avoid the problem, the bootcode on existing boxes must be upgraded before upgrading the main image to 2.1(2).

There is a hidden option in the tftp download menu which allows tftp download of the bootcode. This feature was added in the 1.1.3 and 9.1 versions; it is NOT in the 9.0 version of the code. If you are running something earlier than 9.1 or 1.1.3, this technique will not work. Upgrade to one of those versions first.

Make sure you have the following files from CCO or from the upgrade 3.5 disk:

UNIX DOS
c3000-main-2_1_2.gz C3K_212.GZ
c3000-boot-2_0_1.ima C3K_BOOT.IMA
c3000-mib-2_1_2.mib C3K_212.MIB
c3000-schema-2_1_2.schema C3K_212.SCH
c3000-readme-2_1_2.txt README.TXT

Upgrading the bootcode

Use the following steps to upgrade the bootcode:


Note The bootcode upgrade procedure is the same as the main image download procedure, with the following exception: At the end of the filename, *boot is added so that the filename is downloaded into the boot area.

Step 1 Enter the Download/Upload menu

Step 2 Enter the TFTP Download/Upload... menu

Step 3 Enter your TFTP Server Address, Download VLAN

Step 4 Enter the Main Image Download... menu

Step 5 Download the image. If in a Stack, select "Execute Main Image Stack Network Download"

You can now use the same menu to download the 2.1(2) main image in the normal way. Reset the box after both images are downloaded and the system will come up running 2.1(2).

Recovering from not Upgrading the bootcode first

If you loaded the new 2.1(2) image without the new boot image and reboot the system, then the boot process will fail and you will need to do a serial download of the new bootcode to recover. Serial download is a slow process, but it is the only option available in this case. The following are screen captures of the boot process and the necessary information on how to load the new boot image after the system has been restarted.

Cisco Catalyst Boot Firmware P/N 57-1327-02, Copyright 1995


- Initiating bootstrapping sequence.


- Boot image integrity check...Passed.


- Control transferred to boot process.


- Relocating main image to DRAM.................


The system will remain in this locked up state indefinitely. to resolve this situation, press the reset button on the Catalyst 3x00 system. When the system displays the line "Relocating main image to DRAM" again, press the SYSREQ button momentarily. The following menu should appear on the screen:

Note If you wait until the dots stop printing, it's too late press the SYSREQ button. If you push the SYSREQ button before the dots start printing, you'll go into the debugger. If that happens, push the RESET button and try again

The following menu is displayed:


Figure 1: System Request Menu



Select option 1. The following text is displayed:

SysReq: Beginning Xmodem download of boot image.


SysReq: Waiting for binary file...


Using a Sun workstation:


  1. On a Sun workstation using tip, type:

    ~c (tilde and lowercase 'c')


    This will give you a [cd] prompt. Enter the proper path to the directory containing the boot image. press carriage return.



  2. The following text should appear:

    SysReq: Waiting for binary file...



  3. Now type:

    ~C (tilde and uppercase 'C')


    The following string should appear on the screen:


    ~CLocal command?



  4. In response, type the following:

    sx C3KBOOT.IMA (or the proper name of the boot image)


    The system will download the specified image and will reboot automatically when finished.


On PC's or Other Terminal Emulator Programs


  1. On PC's or other terminal emulator programs simply perform an xmodem send of the file C3KBOOT.IMA (or whatever the file is called)

  2. Use the following menu:

Figure 2: System Request Menu




  1. Select choice one.

  2. The following text is displayed:

    SysReq: Beginning Xmodem download of boot image.


    SysReq: Waiting for binary file...


    ~CLocal command?


    sx epsboot.ima


    Sending C3KBOOT.IMA, 443 XMODEM blocks.


    Give your local XMODEM receive command now.


Sector xx xk

After all the boot image sectors have been downloaded, the following menu is displayed:


Figure 3: System Request Menu




  1. Select choice one.

    SysReq: Beginning Xmodem download of boot image.


    SysReq: Waiting for binary file...


    ~CLocal command?


    sx epsboot.ima


    Sending C3KBOOT.IMA, 443 XMODEM blocks.


    Give your local XMODEM receive command now.


    Sector 442 55k away for 31 seconds!


    Done. (located at 30010000)


    SysReq: Overlaying old boot image and rebooting...



  2. Once this is done, the system will reboot automatically with the new bootcode and the following text is displayed:

Cisco Catalyst Boot Firmware P/N 57-1327-02, Copyright 1995


- Initiating bootstrapping sequence.


- Boot image integrity check...Passed.


- Control transferred to boot process.



Boot Firmware (Phase II) v2.0


- Relocating main image to DRAM..................Done.


- Main image integrity check...succeeded.


- Control transferred to main process.



System Software Version 2.1(2), Copyright 1994-1996.


System started on Xxx. Xxx x, xxxx xx:xx:xx

8 Megabytes System memory

2 Megabytes Network memory

- Initialization started

- File system initialized

- System temperature is within safe operating levels

- Checking file system integrity

- Warmboot initialization started

- LAN ports detected:

- 10Base-T: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

- StkPort : 25

- CPU Network memory test...

- CPU Network memory test...Passed

- Initializing Ports: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 25

- Initializing system address table

- System entering stand-alone mode

- System initialization complete

- Starting SNMPv1 agent task

- Enabling port: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 25

Press RETURN key to activate console...

New Bootcode Support

The new bootcode will support all previous versions of the main image, including 9.0, 9.1, 1.1.3, and 1.3. It is recommended that you upgrade the bootcode on all the systems, even if you are not planning to upgrade them to 2.1(2) immediately, since the problem with the pre 2.0 version of the bootcode will continue to occur with all future releases (2.2, 2.3, etc.).

Preserving a VTP Configuration

The following sections explain how to preserve an existing VTP/VLAN configuration.


Note The following sections apply only if you are going into an existing VTP environment and you want to preserve the present VLAN configuration. If you are not upgrading an existing configuration, ignore the following sections.

How to Integrate a Pre-2.0 Release Into An Existing VTP Environment

As dictated by the VTP specification, the configuration of ports onto old EtherSwitch domains is now constrained by VTP as long the switch is participating in VTP (that is, as long as it isn't in VTP Transparent mode). This means that a local port cannot be assigned to any VLAN which is not configured via VTP. Thus, what used to be called Domain Port Configuration is now essentially VTP VLAN Configuration and the selections available to the user now consist of those defined in VTP rather than the switch's constant 64 choices. When a VTP VLAN is deleted and removed from the database for the administrative domain, all local ports assigned to it automatically become unassigned. An unassigned port does not belong to any VLAN and does not forward packets.

Besides local ports, IP, SNMP, Spanning Tree, and TFTP choices which were previously dependent upon the old domain context are now dependent on the VTP VLAN context. For instance, an IP address configured for the switch is now defined in a VTP VLAN and only applies to IP packets received on that VLAN, whether over a trunk or a local port. When a VTP VLAN is deleted all such parameters are permanently lost. If you don't want to lose the old parameters, you have the option of using the following procedures to reconfigure your switch after you download the 2.1(2) Software Release

Examine the Local VTP Database Created by the Upgrade

With the 2.0 (and subsequent releases) the VTP and VLAN configuration replaces the current domain configuration. After the switch software reads the pre-2.0 configuration database, the new release code modifies the pre-2.0 configuration to create a new 2.0 (or above) configuration (VTP) database.

VTP Transparent Mode

This database places the local Stack in VTP Transparent mode in order to give you the opportunity to complete the necessary manual steps of the upgrade procedure. In Transparent mode, all VTP configuration propagation packets are transparently forwarded to other trunks and are not used for local configuration. Until the Stack leaves Transparent Mode, all VLAN configuration is entirely under local control.

The initial VTP database will contain 68 VLANs: 64 Ethernet VLANs which are created to represent the 64 pre-2.0 Virtual EtherSwitches (what were formerly called Domains in some places) and the four VTP-mandatory non-Ethernet default VLANs which exist in all VTP databases.

The first of the 64 Ethernet VLANs corresponds to the VTP-mandatory default Ethernet VLAN and also to the pre-2.0 default Virtual EtherSwitch. The names of the other Ethernet VTP VLANs should correspond to the names of the Virtual EtherSwitches they replaced. Ports should be assigned to VLANs corresponding to the Virtual EtherSwitch to which they had previously been assigned.

IP, Spanning Tree, SNMP, and TFTP configuration parameters which had previously specified a Virtual EtherSwitch(es) now specify the corresponding VLAN(s)

Analyze and Determine Local VLAN Modifications Needed for Integration

In order to integrate into a VTP-controlled VLAN database environment, it is necessary to leave Transparent Mode and allow the global VTP database to overwrite the local one.

Before you do this, it is important to understand the consequences of this so you can take the necessary steps to prepare the local configuration.

When a device receives a new VTP database which supersedes its existing one, it implements the new database locally as appropriate. If new VLANs (as identified by their VLAN id number) are defined in the new database, then they are created locally. This allows the assignment of local ports to these new VLANs.


Note If old VLANs do not exist in the new database (as identified by their VLAN id number), they will be erased locally. The effect of this is the unassigning of any local ports and parameters (for example, an IP address defined for the Stack on the local VLAN) that are assigned to that VLAN, and permanently losing their configuration information.

Regardless of whether the local device has begun running VTP or not, the trunk mapping of VLANs will occur as specified in the VTP database using VLAN id for ISL trunks and VLAN name for LANE trunks. Whether or not this mapping is appropriate for your configuration depends on which ports on a local Stack need to be members of the same VLAN (with other local assigned ports that exist on remote devices across the trunk and beyond).

Assigning Local Ports

To insure that the local VLAN port and parameter assignments resolve correctly and do not get deleted (once they are controlled by VTP):

For example, after the upgrade procedure, Virtual EtherSwitch 5, named Engineering, with five ports and an IP address of 192.5.5.5, will be changed to VLAN Engineering VTP id number 5 with the same port/IP assignments.

If you need to move VLAN Engineering from VTP id number 5 to another global VLAN with different VTP id number, follow the instructions in the Moving Local VLAN Assignments section.

Moving Local VLAN Assignments

If, in the example in the previous section, the user determines that the ports and address in local VLAN 5 need to be assigned to global VLAN 281 (because this will allow desired connectivity to other ports in global VLAN 281) the VLAN will need to be moved.

Procedure to Move VLANs

First of all, VLAN 281 needs to exist in order to move ports and parameters there. (The VLANs corresponding to the pre-2.0 database created are assigned id numbers 1 through 64 and the mandatory non-ethernet default VLANs are assigned id numbers 1002 through 1005.)

Step 1 The VLAN 281 must be created using the VTP VLAN Configuration Sub-menu (under the VLAN and VTP Configuration Menu.) If integration into the global database is imminent, there is no need to be concerned with most of the VTP parameters assigned to VLAN 281 in the local database since these will ultimately be overwritten by the global database. However, since there is a limit of 68 VLANs on a local device, one of the existing VLANs will need to be deleted to make room for VLAN 281. Use the delete function in this menu to remove a VLAN that is not needed.

Step 2 Add VLAN 281 using the Add function in the VTP VLAN Configuration menu. The parameters that need to be configured are:

The last two values will default as desired (Ethernet type/1500 MTU) when using this function in the VTP VLAN Parameter Configuration Menu. (As covered in a later section, the new VLAN need not and probably should not be made Preferred in the Local Preferred VLANs Configuration menu.)


Step 3 Once VLAN 281 is created, ports and local parameters may be moved from VLAN 5 to VLAN 281. To move a local VLAN in a single step, use the Reassign Ports in Local VLAN sub-menu under the VLAN and VTP Configuration menu.

Step 4 The Reassign Ports in Local VLAN menu has four selectable items:

Step 5 In this example, the source VLAN would be VLAN 5 and the destination VLAN would be VLAN 281. Select the Execute Reassignment function to complete the move. Check that all local static ports and parameters have been moved from VLAN 5 to VLAN 281.

Final Integration

After all local VLAN moves have been executed and the local VLAN configuration appears correct, integrate this information into the global VTP environment. This procedure must be performed carefully since it may have a drastic effect on local configuration. Use the following steps for this procedure:

Step 1 Do a TFTP save of the configuration database. To do this, go to the Downloads/Upload menu and the TFTP Download/Upload sub-menu.

Step 2 To allow access to the system from the outside, go to the VTP Administrative Configuration menu.

Step 3 Set the Local Mode parameter to either Server or Client mode. If the global VTP database contains no secret value (password) and assuming the local environment has only one VTP administrative domain, this is the only necessary procedure you need to do. However, if you have set a secret value, it also will need to be set in the VTP Administrative Configuration menu

The local device learns the administrative domain name from the first peer to subsequently advertise it to the rest.


Step 4 If necessary, the local mode may be reset to Transparent mode and the configuration uploaded back into the device. Do not simply reload the configuration database without resetting the local VTP mode.

Step 5 After a period of time (normally not exceeding five minutes), the global VTP configuration should be received over the default Ethernet VLAN of any ISL or LANE trunk from a VTP peer (not itself in Transparent mode).

Step 6 The local VTP configuration should now be identical to the global one. If the VLAN moves have been done correctly all the ports and parameters should be assigned as desired and connected to ports in remote devices on their corresponding VLANs.

Preferred VLANs as Destinations In The Reassign Ports in Local VLAN Menu

A preferred VLAN is a VLAN that contains configuration parameters such as IP/port assignments. A non-preferred VLAN does not have any local configuration parameters.

The source of a local VLAN move must be a preferred VLAN. This is because only preferred VLANs contain local port and (non-default) parameter assignments.

It is preferable to have the destination of a VLAN move be a non-preferred VLAN with no locally configured parameters.

However, if the destination VLAN of the move has configured values, you can perform one of the following actions:

A further selection on the VLAN and VTP Configuration menu will allow you to choose which of the two VLAN's local IP and Spanning Tree parameters are kept (assigned to the destination VLAN) and which are discarded.

Reassign Ports in Local VLAN

This display is used to move a fully configured Stack into a pre-existing VTP administrative domain.


Figure 4: Reassign Ports in a Local VLAN Menu



An Example of How To Upgrade Into a VTP Environment

The following database (Table 1) assumes you would like to integrate the ports on the VLANs named local-(appropriate name) on the Stack being upgraded to 2.1(1), using VTP, into the corresponding global VLANs name global-(appropriate name). For instance, it is desired that ports 2, 4, and 8 (which originally belonged to local-W on the local Stack will ultimately become members of the VLAN named global-W.


Table  1: VTP Database
Local VTP Database Global VTP Database
VLAN ID # VLAN Name Ports VLAN ID# VLAN Name
1 default 1, 3, 15 1 default
2 local-w 2, 4, 8 2 global-A
3 local-x 5, 10, 16 3 global-B
4 local-y 6, 12, 14 4 global-C
5 local-z 7, 9, 11, 13 5 global-W
6 VLAN 5 6 global-D
7 VLAN 6 8 global-E
8 VLAN 7 12 global-X
9 VLAN 8 25 global-F
10 VLAN 9 67 global-Y
11 VLAN 10 281 global-Z
.
.
.
.
64 VLAN 63

  1. The Local VTP Database is an example of what might be found in the VTP VLAN configuration after the upgraded box boots up the first time. The "Global" database is the one found in any box in the network currently running VTP in non-transparent mode.

  2. In the section, Analyze and Determine Local VLAN Modifications Needed for Integration, the user needs to move the local ports and parameters initially assigned to VLAN 2 into VLAN 5. Those assigned to VLAN 3 will be moved to VLAN 12. Those assigned to VLAN 4 will be moved to VLAN 67, and those assigned to VLAN 5 will be moved to VLAN 281. The user would not care about local VLANs numbers over 5 if there are no ports or parameters assigned to them.

  3. In the section, Moving Local VLAN Assignments, the user would move the VLANs as planned in section, Analyze and Determine Local VLAN Modifications Needed for Integration. Since VLANs 67 and 281 do not exist on the local database, the user would need to first delete two unneeded local VLANs (for instance, VLAN 63 and VLAN 64), and then add VLANs 67 and 281. All of this is done in transparent mode.

  4. Since VLAN 12 already exists and is preferred (all of the 64 Ethernet VLANs created during upgrade are created as preferred VLANs), it does not have to be created. However, the user needs to choose between swapping VLAN 3 with it or merging VLAN 3 into it. It doesn't matter how it is handled since the user didn't have anything in VLAN 12 that is needed to be saved.

  5. Since VLAN 5 already exists and is important to the user, the user must take care to handle it correctly when doing the move from VLAN 2 to VLAN 5. Move local-z to the newly created VLAN 281 before moving local-w to VLAN 5.

    As an alternative, you could swap VLANs 2 and 5 first, thus moving the ports and parameters of local-z to local-w and vice versa. (Note that the names do not move.) Then move VLAN 2 to VLAN 281.



  6. Once the four move operations are performed, the user (after TFTP saving the configuration), may change the local Stack into VTP server or client mode.

After this has been done (and sufficient time has passed such the configuration has propagated from a neighboring device or Stack running VTP), the Local database should go away completely and the user will see the Global database implemented on the upgraded Stack. All the ports and parameters should have survived the move, however, and will be found in the VLANs they were assigned to by VLAN id number before the mode was changed.

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


Note If you purchased your product from a reseller, you can access Cisco Connection Online (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 Online

CCO is Cisco Systems' primary, real-time support channel. SMARTnet customers and partners can self-register on CCO to obtain additional information and services.


Note If you purchased your product from a reseller, you can access CCO as a guest. Your reseller offers programs that include direct access to CCO's 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:

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 need technical assistance with a Cisco product that is under warranty or covered by a Cisco maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com.

Please use CCO to obtain general information about Cisco Systems, Cisco products, or upgrades. If CCO is not accessible, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.



hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1997 © Cisco Systems Inc.