Table of Contents
Release Notes for Catalyst 5000 Family Gigabit EtherChannel Switching Module Software Release 4.x
Current Release (September 29, 2000)
4.5(9)
Previous Releases
4.5(6), 4.5(2), 4.5(1), 4.3(1), 4.2(1)
These release notes describe the features, modifications, and caveats for the Catalyst 5000 family Gigabit EtherChannel switching module (WS-X5410) software release 4.x. The current software release is version 4.5(9).
For features, modifications, and caveats for the Catalyst 5000 family supervisor engine software, refer to the appropriate release notes for your Catalyst 5000 family software release.
 |
Note The Gigabit EtherChannel module has been packaged with the latest version of Gigabit EtherChannel software. However, before this module can run in your Catalyst 5000 family switch, you must load Catalyst 5000 family supervisor engine software release 4.2(1) or later on your supervisor engine module. A copy of 4.2(1) or a later version is provided on DOS floppy disks that ship with the product. Software images are also available via File Transfer Protocol (FTP) as described in the "Cisco Connection Online" section. |
This document consists of these sections:
Table 1 lists the minimum and recommended Gigabit EtherChannel software versions for Cisco GBICs
.
Table 2 lists the software images available for Gigabit EtherChannel module software release 4.x.
Table 2: Gigabit EtherChannel Module Software Ordering Information
| Version Number
| Filename
| Orderable Product Number
(Flash on System)
| Orderable Product Number
(Spare Upgrade - Floppy Media)
|
|---|
4.2(1)
| c5gem.4-2-1.bin
| SFC5K-GEM-4.2.1
| SWC5K-GEM-4.2.1=
|
4.3(1)
| c5gem.4-3-1.bin
| SFC5K-GEM-4.3.1
| SWC5K-GEM-4.3.1=
|
4.5(1)
| c5gem.4-5-1.bin
| SFC5K-GEM-4.5.1
| SWC5K-GEM-4.5.1=
|
4.5(2)
| c5gem.4-5-2.bin
| SFC5K-GEM-4.5.2
| SWC5K-GEM-4.5.2=
|
4.5(6)
| c5gem.4-5-6.bin
| SFC5K-GEM-4.5.6
| SWC5K-GEM-4.5.6=
|
4.5(9)
| c5gem.4-5-9.bin
| SC5K-GEM-4.5.9
| SC5K-GEM-4.5.9=
|
This section describes usage guidelines and restrictions that apply to the Gigabit EtherChannel switching module.
- Use of the Gigabit EtherChannel module requires Catalyst 5000 family supervisor engine software release 4.2(1) or later with Gigabit EtherChannel module software release 4.2(1) or later.
- If you plan to use the Gigabit EtherChannel module in a Catalyst 5000 switch chassis or with Supervisor Engine I or II, use Gigabit EtherChannel module software release 4.3(1) or later with supervisor engine software release 4.3(1) or later. Prior to software release 4.3(1), the Gigabit EtherChannel module was not fully tested with this hardware.
This section describes the open and resolved caveats in Gigabit EtherChannel module software release 4.5(9):
This section describes open caveats in Gigabit EtherChannel module software release 4.5(9).
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
This section describes the caveats resolved in Gigabit EtherChannel module software release 4.5(9).
- Many protocols implemented on the Catalyst 5000 family switches (for example CGMP) require the port location of a particular MAC address. To determine the port location, the Host Table usually needs to be sorted through because SNMP getNext operations use a host's MAC address as an index in the table. This operation is not required to determine the port location of a specific MAC address but is performed anyway. This problem is resolved in software release 6.1(1). (CSCdp90079)
- When a Catalyst 4000 family or 2948G series has a large number (greater than 5000) of active paths packets sometimes get reordered. An active path is a SA, DA pair. Reordered packets may cause SNA sessions to drop. There is no workaround. (CSCdr68833)
This section describes the open and resolved caveats in Gigabit EtherChannel module software release 4.5(6):
This section describes open caveats in Gigabit EtherChannel module software release 4.5(6).
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
This section describes the caveats resolved in Gigabit EtherChannel module software release 4.5(6).
- You might occasionally see the following sync-loss error message:
6/C5man:Gigmac Link A, Mac rcv sync loss error, status reg is:0x00
- If rx sync is lost, in most cases it will be reestablished quickly. A single occurrence, or even a burst of these messages in a given time is not a problem. If the messages become excessive, the card will be reset so that power-on-self-tests (POST) can be performed. If POST diagnoses an error, the module is kept offline so that network redundancies can be activated. This problem is resolved in software release 4.5(6). (CSCdp33738)
- When the native VLAN of a trunk port is cleared and then the trunk port is set to off, the port is placed in the inactive state but the Link LED for the port still shows green. The correct behavior is that the LED for the port should show orange. This problem is resolved in software release 4.5(6). (CSCdk31985)
This section describes the open and resolved caveats in Gigabit EtherChannel module software release 4.5(2):
This section describes open caveats in Gigabit EtherChannel module software release 4.5(2).
- When the native VLAN of a trunk port is cleared and then the trunk port is set to off, the port is placed in the inactive state but the Link LED for the port still shows green. The correct behavior is that the LED for the port should show orange. (CSCdk31985)
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
This section describes the caveats resolved in Gigabit EtherChannel module software release 4.5(2).
- In some situations, if the Gigabit EtherChannel module (WS-X5410) attempts to clear dynamic CAM table entries when the dynamic entries have not been cleared for an extended period of time (several days to several weeks), the module resets. Events that cause the module to clear dynamic CAM entries include:
- Entering the clear cam dynamic command
- A link-down on a port on the module, causing the module to clear entries learned on that port
- This problem is resolved in software release 4.5(2). (CSCdm33046)
- If the local CAM table on the Gigabit EtherChannel module (WS-X5410) is nearly full, when you enter the clear cam dynamic command, it might take up to three seconds to execute, during which time the CLI is unresponsive and MAC address learning and traffic switching for frames with new MAC addresses does not occur on the module (traffic for hosts already learned is unaffected). The workaround is to set the CAM agingtime to a low value (for example, 15 seconds), waiting for the CAM entries to age out, and then setting the CAM aging time to its previous value. This problem is resolved in software release 4.5(2). (CSCdk35247)
- In some cases, if you disconnect and then reconnect the fiber-optic cable from a GBIC on the Gigabit EtherChannel module (WS-X5410), the port fails to establish a link. The workaround is to remove and reinsert the GBIC (if you are connecting to a second Gigabit EtherChannel module, you might have to reseat the GBIC on the second module as well), or disable and reenable the ports on both the Gigabit EtherChannel module and the connected device. This problem is resolved in software release 4.5(2). (CSCdm24585)
This section describes the open and resolved caveats in Gigabit EtherChannel module software release 4.5(1):
This section describes open caveats in Gigabit EtherChannel module software release 4.5(1).
- When the native VLAN of a trunk port is cleared and then the trunk port is set to off, the port is placed in the inactive state but the Link LED for the port still shows green. The correct behavior is that the LED for the port should show orange. (CSCdk31985)
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
- In some situations, if the switch attempts to clear dynamic CAM table entries when the dynamic entries have not been cleared for an extended period of time (several days to several weeks), the switch resets. Events that cause the switch to clear dynamic CAM entries include:
- Entering the clear cam dynamic command
- A link-down on a switch port, causing the switch to clear entries learned on that port
- (CSCdm33046)
This section describes the caveats resolved in Gigabit EtherChannel module software release 4.5(1).
- In some cases, the Wandel and Goltermann Domino network analyzer might have trouble autonegotiating with the Gigabit EtherChannel module. This problem is resolved in Domino software version 2.4. (CSCdk34804)
- When two 802.1Q-capable peers are in the process of negotiating the trunking status of a link, they might become temporarily inconsistent. Under certain circumstances, such as a spanning-tree loop or if prolonged line-rate traffic exists, this inconsistency might persist for tens of seconds.
- During the period of inconsistency, if one side believes that it is trunking and the other side believes that it is not trunking, the following message appears on the non-trunking side:
07/30/1998,11:07:18:SPANTREE-2: Rcved 1Q-BPDU on non-1Q-trunk port <mod>/<port> vlan
<vlan>
- In the default configuration, this message appears approximately once per VLAN, every two seconds. The message indicates that the trunk states are inconsistent between the local switch and the link partner.
- The solution is to address the trunking inconsistency between the link partners and investigate why there are persistently high rates of traffic on that link. This problem is resolved in software release 4.5(1). (CSCdk29882)
- If the switch CAM table is 32K or larger in size, a Catalyst 5000 family switch with a Gigabit EtherChannel module might generate the following warning an excessive number of times (where mod_num is the slot in which the module is installed):
%TIMESTAMP: SYS-3: mod_num/No vlan host table memory to add entry for addr mac_addr
- This problem is resolved in software release 4.5(1). (CSCdk43458)
- The output from the show spantree mod_num/port_num command shows Gigabit EtherChannel module ports 5 through 9 as a four-port channel. The display should show ports 5 through 8 as the four-port channel. The Gigabit EtherChannel module supports channel groups for ports 1 through 4 and ports 5 through 8. Port 9 cannot be channeled with any other port. This problem is resolved in software release 4.5(1). (CSCdk25123)
- If a Catalyst 5000 family switch is configured as a VTP client and its only connection to the VTP server is through a port on the Gigabit EtherChannel module (WS-X5410) that is configured as an IEEE 802.1Q trunk with its native VLAN other than VLAN 1, when the system is reset the trunk port might fail to enter trunking mode after the system comes online (the show trunk command output shows the trunk in the "inactive" state). The workaround is to reset the module on which the trunk port is located or set the native VLAN of the trunk port to VLAN 1. This problem is resolved in software release 4.5(1). (CSCdk77956)
- In a switch with the Gigabit EtherChannel module (WS-X5410) and redundant supervisor engines, a switchover from the active to the standby supervisor engine might occur slowly (up to a 15 second delay). This problem is resolved in software release 4.5(1). (CSCdm00348)
- If a switch with the Gigabit EtherChannel module (WS-X5410) learns the MAC address of a host advertising a MAC address of 00:00:00:00:00:00, when you enter the show cam dynamic command, the module will reset. This MAC address is illegal, but some non-compliant hardware might advertise this address. The workaround is to not enter the show cam dynamic command if a MAC address of all zeroes has been learned on a switch with a Gigabit EtherChannel module. This problem is resolved in software release 4.5(1). (CSCdm05261)
These sections describe the open and resolved caveats in Gigabit EtherChannel module software release 4.3(1):
This section describes open caveats in Gigabit EtherChannel module software release 4.3(1).
- In some cases, when you power cycle a Catalyst 5000 family chassis with the Gigabit EtherChannel module installed, when the switch reboots the module is not recognized and does not come online (a "Serial EEPROM not set" message appears on the console). The workaround is to physically remove and reinsert the module in the chassis. (CSCdk53525)
|
Note CSCdk53525 has not been seen in later releases. |
- In some cases, entering the clear config command on a Catalyst 5000 family switch with a Supervisor Engine II and a Gigabit EtherChannel module installed might cause the console session to hang. The workaround is to reset the switch. (CSCdk51099)
|
Note CSCdk51099 has not been seen in later releases. |
- When the native VLAN of a trunk port is cleared and then the trunk port is set to off, the port is placed in the inactive state but the Link LED for the port still shows green. The correct behavior is that the LED for the port should show orange. (CSCdk31985)
- In some cases, the Wandel and Goltermann Domino network analyzer might have trouble autonegotiating with the Gigabit EtherChannel module when you perform the following actions:
- 1. Connect the Gigabit EtherChannel module to the analyzer (the link comes up)
- 2. Quit and restart the analyzer software (the link does not come up)
- The workaround is to disconnect the cable from the port and then reconnect it or disable the Gigabit EtherChannel module port using the set port disable command and then reenable the port using the set port enable command. No further autonegotiation problems occur until you quit and restart the analyzer software again. This problem is resolved in Domino software version 2.4. (CSCdk34804)
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
- If the CAM table on the Gigabit EtherChannel module is nearly full (capacity of 16,384 MAC addresses), the clear cam dynamic command can take up to three seconds to complete. This stops all activity on the Gigabit EtherChannel module and can cause a delayed response from the supervisor engine command-line interface (CLI).
- The workaround is to set the cam aging time to a low value using the set cam agingtime command. For example, specify 15 seconds, wait for at least one full aging time (in this case 15 seconds) and then increase the aging time to its previous value. This clears the CAM table for the specified VLAN. (CSCdk35247)
- When two 802.1Q-capable peers are in the process of negotiating the trunking status of a link, they might become temporarily inconsistent. Under certain circumstances, such as a spanning-tree loop or if prolonged line-rate traffic exists, this inconsistency might persist for tens of seconds.
- During the period of inconsistency, if one side believes that it is trunking and the other side believes that it is not trunking, the following message appears on the non-trunking side:
07/30/1998,11:07:18:SPANTREE-2: Rcved 1Q-BPDU on non-1Q-trunk port <mod>/<port> vlan
<vlan>
- In the default configuration, this message appears approximately once per VLAN, every two seconds. The message indicates that the trunk states are inconsistent between the local switch and the link partner.
- The solution is to address the trunking inconsistency between the link partners and investigate why there are persistently high rates of traffic on that link. This problem is resolved in software release 4.5(1). (CSCdk29882)
- If the switch CAM table is 32K or larger in size, a Catalyst 5000 family switch with a Gigabit EtherChannel module might generate the following warning an excessive number of times (where mod_num is the slot in which the module is installed):
%TIMESTAMP: SYS-3: mod_num/No vlan host table memory to add entry for addr mac_addr
- This problem is resolved in software release 4.5(1). (CSCdk43458)
- The output from the show spantree mod_num/port_num command shows Gigabit EtherChannel module ports 5 through 9 as a four-port channel. The display should show ports 5 through 8 as the four-port channel. The Gigabit EtherChannel module supports channel groups for ports 1 through 4 and ports 5 through 8. Port 9 cannot be channeled with any other port. This problem is resolved in software release 4.5(1). (CSCdk25123)
- If a switch with the Gigabit EtherChannel module (WS-X5410) learns the MAC address of a host advertising a MAC address of 00:00:00:00:00:00, when you enter the show cam dynamic command, the module will reset. This MAC address is illegal, but some non-compliant hardware might advertise this address. The workaround is to not enter the show cam dynamic command if a MAC address of all zeroes has been learned on a switch with a Gigabit EtherChannel module. This problem is resolved in software release 4.5(1). (CSCdm05261)
This section describes the caveats resolved in Gigabit EtherChannel module software release 4.3(1).
- In a Catalyst 5000 family switch with a Supervisor Engine III with the NFFC or NFFC II, when the Gigabit EtherChannel module comes online you might see this syslog message: "SYS-3:LLC send scp message failed." You can safely ignore this message. This problem is resolved in software release 4.3(1). (CSCdk52467)
- If you connect two Gigabit EtherChannel modules through a four-port trunked channel and you disable a port in the channel on one module, the connected port on the other module is incorrectly placed in the "errdisable" state. The problem only occurs under heavy traffic conditions. This problem is resolved in software release 4.3(1). (CSCdk45349)
- If you enable SPAN twice on the Gigabit EtherChannel module (using the set span enable command), the Gigabit EtherChannel module changes the Oper Source port configuration to an incorrect configuration. This problem is resolved in software release 4.3(1). (CSCdk32267)
- If you perform the following actions, a Gigabit EtherChannel module port might fail to operate correctly even though all indications show the port to be operational:
- 1. Unplug the port, bringing down the link (or disable the link at the far end).
- 2. Make the port a SPAN destination using the set span command.
- 3. Plug the port in, bringing up the link (or reenable the port at the far end).
- 4. Disable SPAN using the set span disable command.
- This problem is resolved in software release 4.3(1). (CSCdk31744)
- Setting the monitorSourcePort.0 MIB object to a value greater than 1023 is not rejected as an illegal value. This problem is resolved in software release 4.3(1). (CSCdk26394)
- If you modify the flow control configuration on one port in a Gigabit EtherChannel bundle, the entire channel is torn down and renegotiated. The correct behavior is that only the modified port and its connected neighbor are affected by the configuration change, while the other ports in the channel remain undisturbed. This problem is resolved in software release 4.3(1). (CSCdk38766)
This section describes open caveats in Gigabit EtherChannel module software release 4.2(1).
- When the native VLAN of a trunk port is cleared and then the trunk port is set to off, the port is placed in the inactive state but the Link LED for the port still shows green. The correct behavior is that the LED for the port should show orange. (CSCdk31985)
- In some cases, the Wandel and Goltermann Domino network analyzer might have trouble autonegotiating with the Gigabit EtherChannel module when you perform the following actions:
- 1. Connect the Gigabit EtherChannel module to the analyzer (the link comes up)
- 2. Quit and restart the analyzer software (the link does not come up)
- The workaround is to disconnect the cable from the port then reconnect it or disable the Gigabit EtherChannel module port using the set port disable command and then reenable the port using the set port enable command. No further autonegotiation problems occur until you quit and restart the analyzer software again. This problem is resolved in Domino software version 2.4. (CSCdk34804)
- In some situations, a hot-inserted Gigabit EtherChannel module might fail to come online. The problem might occur more frequently when a Token Ring module is installed in the chassis.
- The workaround is to reset the Gigabit EtherChannel module using the reset mod_num command. If the problem persists, reset the Token Ring module (if installed). Reset additional modules as necessary until all modules are online. (CSCdk34829)
|
Note CSCdk34829 has not been seen in later releases. |
- If you reset the Gigabit EtherChannel module using the reset mod_num command during a normal software download to the module (using the download host file [mod_num] command), the supervisor engine might report that the Flash image on the Gigabit EtherChannel module is corrupted, and further attempts to download using the normal method will fail.
- The workaround is to use the reload and download scp commands, as follows:
Console> (enable) reload mod_num
Console> (enable) download [tftp_server] [file_name] [mod_num] scp
- (CSCdk37860)
|
Note CSCdk37860 has not been seen in later releases. |
- The output from the show spantree mod_num/port_num command shows Gigabit EtherChannel module ports 5 through 9 as a four-port channel. The display should show ports 5 through 8 as the four-port channel. The Gigabit EtherChannel module supports channel groups for ports 1 through 4 and ports 5 through 8. Port 9 cannot be channeled with any other port. This problem is resolved in software release 4.5(1). (CSCdk25123)
- If you perform the following actions, a Gigabit EtherChannel module port might fail to operate correctly even though all indications show the port to be operational:
- 1. Unplug the port, bringing down the link (or disable the link at the far end).
- 2. Make the port a SPAN destination using the set span command.
- 3. Plug the port in, bringing up the link (or reenable the port at the far end).
- 4. Disable SPAN using the set span disable command.
- The workaround is to disable the Gigabit EtherChannel module port using the set port disable command and then reenable the port using the set port enable command. This problem is resolved in software release 4.3(1). (CSCdk31744)
- On the Gigabit EtherChannel module (WS-X5410), if a host allowed on one secured port is moved to another, previously unused secured port on the same module, the host cannot connect to the network on the second port. The workaround is to disable port security on the first port, move the host to the second port, and then reenable port security on the first port (if desired). (CSCdk31747)
- If you enable SPAN twice on the Gigabit EtherChannel module (set span enable command), the Gigabit EtherChannel module changes the Oper Source port configuration to an incorrect configuration.
- An example follows:
Console> (enable) show span
Status : disabled
Admin Source : Port 3/5
Oper Source : None
Destination : Port 3/9
Direction : transmit/receive
Incoming Packets: disabled
Console> (enable)
Console> (enable) set span enable
Enabled monitoring of Port 3/5 transmit/receive traffic by Port 3/9
Console> (enable)
Console> (enable) show span
Status : enabled
Admin Source : Port 3/5
Oper Source : Port 3/5-8
Destination : Port 3/9
Direction : transmit/receive
Incoming Packets: disabled
Console> (enable)
Console> (enable) set span 3/5 3/9
Enabled monitoring of Port 3/5 transmit/receive traffic by Port 3/9
Console> (enable)
Console> (enable) show span
Status : enabled
Admin Source : Port 3/5
Oper Source : Port 3/5,3/7-8
Destination : Port 3/9
Direction : transmit/receive
Incoming Packets: disabled
Console> (enable)
- In the first instance, the Gigabit EtherChannel module channel ports are 3/5-8; in the second instance, the ports are 3/5, 3/7-8 (port 3/6 is not included). This problem is resolved in software release 4.3(1). (CSCdk32267)
- If the CAM table on the Gigabit EtherChannel module is nearly full (capacity of 16,384 MAC addresses), the clear cam dynamic command can take up to three seconds to complete. This stops all activity on the Gigabit EtherChannel module and can cause a delayed response from the supervisor engine command-line interface (CLI).
- The workaround is to set the cam aging time to a low value using the set cam agingtime command. For example, specify 15 seconds, wait for at least one full aging time (in this case 15 seconds) and then increase the aging time to its previous value. This clears the CAM table for the specified VLAN. (CSCdk35247)
- Setting the monitorSourcePort.0 MIB object to a value greater than 1023 is not rejected as an illegal value. This problem is resolved in software release 4.3(1). (CSCdk26394)
- When two 802.1Q-capable peers are in the process of negotiating the trunking status of a link, they might become temporarily inconsistent. Under certain circumstances such as a spanning-tree loop or if prolonged line-rate traffic exists, this inconsistency might persist for tens of seconds.
- During the period of inconsistency, if one side believes that it is trunking and the other side believes that it is not trunking, the following message appears on the non-trunking side:
07/30/1998,11:07:18:SPANTREE-2: Rcved 1Q-BPDU on non-1Q-trunk port <mod>/<port> vlan
<vlan>
- In the default configuration, this message appears approximately once per VLAN, every two seconds. The message indicates that the trunk states are inconsistent between the local switch and the link partner.
- The solution is to address the trunking inconsistency between the link partners and investigate why there are persistently high rates of traffic on that link. This problem is resolved in software release 4.5(1). (CSCdk29882)
- If a switch with the Gigabit EtherChannel module (WS-X5410) learns the MAC address of a host advertising a MAC address of 00:00:00:00:00:00, when you enter the show cam dynamic command, the module will reset. This MAC address is illegal, but some non-compliant hardware might advertise this address. The workaround is to not enter the show cam dynamic command if a MAC address of all zeroes has been learned on a switch with a Gigabit EtherChannel module. This problem is resolved in software release 4.5(1). (CSCdm05261)
The following documents are available for Catalyst 5000 family switches:
- Quick Installation Guides—Available for the Catalyst 5002, Catalyst 5000 and Catalyst 5005, Catalyst 5509, and Catalyst 5500
- Catalyst 5000 Series Installation Guide
- Catalyst 5000 Series Supervisor Engine Installation Guide
- Catalyst 5000 Series Module Installation Guide
- Catalyst 5000 Series Quick Software Configuration
- Software Configuration Guide—Catalyst 5000, 4000, 2948G, 2926G, and 2926 Series Switches
- Command Reference—Catalyst 5000, 4000, 2948G, 2926G, and 2926 Series Switches
- System Message Guide—Catalyst 5000, 4000, 2948G, 2926G, and 2926 Series Switches
- Troubleshooting Tips—Catalyst 5000, 4000, 2948G, 2926G, and 2926 Series Switches
- Enterprise MIB User Quick Reference (online only)
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 and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Cisco Connection Online (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:
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. |
Posted: Mon Oct 2 16:36:50 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
