Table of Contents
Release Notes for Catalyst 6000 Family Multilayer Switch Feature Card
Cisco IOS Release 12.0 XE
Current Release (February 7, 2000): 12.0(7)XE1
Previous Releases:
12.0(7)XE (Deferred), 12.0(3)XE2 (Deferred), 12.0(3)XE1 (Deferred)
 | Caution
Use these Release Notes if you are running Catalyst software on the supervisor engine and Cisco IOS Release 12.0 XE on the MSFC. These Release Notes do not apply to the Cisco IOS on the Catalyst 6000 Family Release 12.0 XE Supervisor Software product, which runs Cisco IOS Release 12.0 XE on both the supervisor engine and the MSFC (refer to the Release Notes for Catalyst 6000 Family for Cisco IOS Release 12.0 XE publication). |
Note For information about the deferral of 12.0(7)XE and 12.0(3)XE1, refer to the Field Notice at:
http://www.cisco.com/warp/customer/770/fn11211.shtml
These release notes describe the features, modifications, and caveats for Cisco IOS Release 12.0 XE on the Catalyst 6000 family Multilayer Switch Feature Card (MSFC). These release notes are applicable to Release 12.0(7)XE1 and previous releases. For features, modifications, and caveats for the Catalyst 6000 family supervisor engine software, refer to the Release Notes for Catalyst 6000 Family Software Release 5.x document.
Note The MSFC ships with Cisco IOS software installed. Ensure that the Catalyst 6000 family supervisor engine is running supervisor engine software release release 5.3(1a)CSX or later. Software images are available through Cisco Connection Online (CCO); see the "Cisco Connection Online" section for details.
This document consists of these sections:
Note Cisco IOS Release 12.1(1)EX supports the Catalyst 6000 family MSFC router daughtercard and FlexWAN module (refer to the Release Notes for Catalyst 6000 Family MSFC Cisco IOS Release 12.1(1)EX).
Cisco IOS Release 12.0 XE supports the Catalyst 6000 family Multilayer Switch Feature Card (MSFC). Release 12.0 XE is based on Cisco IOS Release 12.0 T.
Release 12.0 XE will be merged into Release 12.1 E, which will eventually be merged into 12.1 T. All maintenance updates will be placed into Cisco IOS Release 12.1 E releases. No maintenance updates will be placed into Release 12.0 XE.
For more information about the Cisco IOS software release process, see the Cisco IOS Software Releases: Product Bulletin #537 located on CCO and on the Documentation CD-ROM.
These release notes do not describe features that are available in Release 12.0, Release 12.0 T, or other Release 12.0 Early Deployment (ED) releases.
For information about features in Release 12.0, see the Cross-Platform Release Notes for Cisco IOS Release 12.0 on CCO and the Documentation CD-ROM.
For information about features in other platforms, see the Release Notes for Cisco IOS Release 12.0 index on CCO and the Documentation CD-ROM.
For a list of the software caveats that apply to Release 12.0(7)XE1, see the "Open and Resolved Caveats in Release 12.0(7)XE1" section, the Caveats for Cisco IOS Release 12.0 T document, and the Caveats for Cisco IOS Release 12.0 document that accompany these release notes. All caveats in Release 12.0 and Release 12.0 T are also in Release 12.0 XE1. The caveats documents are updated for every maintenance release and are located on Cisco Connection Online (CCO) and the Documentation CD-ROM.
The following MSFC default memory configurations are acceptable for all MSFC images:
- 64-MB synchronous dynamic random-access memory (SDRAM) DIMM
- 16-MB Flash SIMM
Note While 64 MB is the minimum acceptable DRAM configuration for IOS Release 12.0(7)XE1, 128MB of DRAM is recommended for most applications.
Table 1 lists the images available for the MSFC and their order numbers:
Table 1: Software Ordering Information
| Filename
| Description
| Orderable
Product Number
(Flash on System)
| Orderable
Product Number
(Spare Upgrade—Floppy Media)
|
|---|
c6msfc-boot-mz.120-7.XE1.bin
| Boot loader
| N/A
| N/A
|
c6msfc-js-mz.120-7.XE1.bin
| Catalyst 6000 Family MSFC Enterprise
| SC6MSFCA-12.0.7XE
| SC6MSFCA-12.0.7XE=
|
c6msfc-ds-mz.120-7.XE1.bin
| Catalyst 6000 Family MSFC Desktop
| SC6MSFCB-12.0.7XE
| SC6MSFCB-12.0.7XE=
|
c6msfc-is-mz.120-7.XE1.bin
| Catalyst 6000 Family MSFC IP
| SC6MSFCC-12.0.7XE
| SC6MSFCC-12.0.7XE=
|
c6msfc-ds-mz.120-7.XE1.bin
| Catalyst 6000 Family MSFC IP/IPX
| SC6MSFCD-12.0.7XE
| SC6MSFCD-12.0.7XE=
|
Note Releases 12.0(7)XE, 12.0(3)XE2, and 12.0(3)XE1 are deferred.
The orderable software images contain the following feature sets:
- The IP feature set includes support for wire speed Layer 2 switching (bridging) and Layer 3 switching (routing). IP routing protocols supported include RIPv1, RIPv2, OSFP, IGRP, EIGRP, EGP, and BGP4.
Note EGP, BGP4 and IS-IS routing protocols require the additional purchase of the InterDomain Routing Feature License (FR-IRC6).
- The IP/IPX feature set adds support for wire speed IPX Layer 3 switching.
- The Desktop feature set adds support for AppleTalk Phase 1/2, DECnet Phase IV, and IS-IS routing.
- The Enterprise feature set adds support for DECnet Phase V and CLNS/OSI routing.
- IOS Release 12.0(7)XE1 supports the High Availability feature in supervisor engine software release 5.4(1) and later. There are no IOS commands or configuration required on the MSFC for the High Availability feature.
- IOS Release 12.0(7)XE1 supports the private VLAN (PVLAN) feature in supervisor engine software release 5.4(1) and later.
- Use the show pvlan command to display information about PVLANs.
- The show pvlan command displays information about PVLANs only when the primary PVLAN is up.
- Entry of set pvlan mapping or clear pvlan mapping commands on the supervisor engine generates MSFC syslog messages. For example:
%PV-6-PV_MSG:Created a private vlan mapping, Primary 100, Secondary 101
%PV-6-PV_MSG:Created a private vlan mapping, Primary 200, Secondary 201
%PV-6-PV_MSG:Purged a private vlan mapping, Primary 100, Secondary 101
- You can enter the interface vlan command to configure Layer 3 parameters only for primary PVLANs.
- On the supervisor engine, you cannot create isolated or community VLANs using VLAN numbers for which interface vlan commands have been entered on the MSFC.
- ARP entries learned on Layer 3 PVLAN interface are sticky ARP entries (we recommend that you display and verify PVLAN interface ARP entries).
- For security reasons, PVLAN interface sticky ARP entries do not age out. Connecting new equipment with the same IP address generates a message and the ARP entry is not created.
- Since the PVLAN interface ARP entries do not age out, you must manually remove PVLAN interface ARP entries if a MAC address changes.
- You can add or remove PVLAN ARP entries manually. For example:
obelix-rp(config)#no arp 11.1.3.30
IP ARP:Deleting Sticky ARP entry 11.1.3.30
obelix-rp(config)#arp 11.1.3.30 0000.5403.2356 arpa
IP ARP:Overwriting Sticky ARP entry 11.1.3.30, hw:00d0.bb09.266e by hw:0000.5403.2356
- Some commands clear and recreate PVLAN mapping. For example:
obelix-rp(config)#xns routing
obelix-rp(config)#
%PV-6-PV_MSG:Purged a private vlan mapping, Primary 100, Secondary 101
%PV-6-PV_MSG:Purged a private vlan mapping, Primary 100, Secondary 102
%PV-6-PV_MSG:Purged a private vlan mapping, Primary 100, Secondary 103
%PV-6-PV_MSG:Created a private vlan mapping, Primary 100, Secondary 101
%PV-6-PV_MSG:Created a private vlan mapping, Primary 100, Secondary 102
%PV-6-PV_MSG:Created a private vlan mapping, Primary 100, Secondary 103
The features listed below were introduced but not fully tested at wire rate in supervisor engine software release 5.3(1a)CSX and MSFC IOS releases 12.0(3)XE1 and 12.0(3)XE2. They have been fully tested in 5.3(3)CSX and MSFC IOS release 12.0(7)XE and are fully operational.
- IPX MLS at wire rate (software release 5.3(1a)CSX and MFSC IOS release 12.0(7)XE or later does support IPX routing at wire rate)
- IOS IPX ACLs at wire rate (software release 5.3(1a)CSX and MFSC IOS release 12.0(7)XE or later does support standard and extended IOS IPX ACLs at wire rate)
- QoS IPX ACLs
There are no new features in Release 12.0(3)XE2.
For a complete list of features, refer to the Catalyst 6000 Family Multilayer Switch Feature Card and Policy Feature Card Configuration Guide.
This section provides usage guidelines and restrictions for using the MSFC:
- Integrated Routing and Bridging (IRB) and Concurrent Routing and Bridging (CRB) have deliberately been disabled on the Catalyst 6000 family switches. Routable Layer 2 VLANs and VLAN interfaces should be used for normal bridging and inter-VLAN routing. Bridge groups are supported only to bridge non-routable protocols.
- If the Catalyst 6000 family switch is being used to switch thousands of IPX flows which may all arrive in simultaneous bursts, we recommend that you configure the following to avoid excessive CPU load:
Router(config)# ipx route-cache inactivity-timeout 1 100.
- The above sets the IPX cache inactivity-timeout to 1 minute and the maximum invalidations per minute to 100.
- Before you can use a system image stored on the supervisor engine Flash PC card, you must set the BOOTLDR environment variable. In privileged mode, enter the boot bootldr bootflash: boot_loader_image command.
- Data-link switching plus (DLSw+) was mistakenly identified as not being supported in MSFC IOS release 12.0(3)XE1 and subsequent releases. DLSw+ is supported in 12.0(3)XE1 and subsequent releases.
- Cisco IOS Release 12.0(3)XE1 and subsequent releases support:
- The Web Cache Control Protocol (WCCP) feature, versions 1 and 2
- In addition to the Layer 3 routing protocols listed in the Catalyst 6000 Family MSFC(12.0) & PFC Configuration Guide: Apollo, AppleTalk Routing, DECnet, VINES, and XNS
- At power up or manual reset you must configure the MSFC to boot from its bootflash (or the supervisor engine's Flash PC card; however, bootflash is preferred). When you reset the supervisor engine through either a power up or a manual reset, the MSFC cannot boot from a TFTP server on the network. However, when the supervisor engine is up and the port over which the network is being accessed is in forwarding state, you can boot the MSFC from a TFTP server on the network.
- In a redundant supervisor engine setup, if a specific VLAN interface on one MSFC is shut down, you should manually shut down the corresponding VLAN interface on the other MSFC.
- By default, the MSFC sends Internet Control Message Protocol (ICMP) unreachables when a packet is denied by an access group; these access-group-denied packets are not dropped in hardware but are bridged to the MSFC so it can generate the ICMP-unreachable message. To drop access-group-denied packets in hardware, you must disable ICMP unreachables using the no ip unreachables interface configuration command. Note that the ip unreachables command is enabled by default.
- You can specify the MSFC as the MLS route processor (MLS-RP) for Catalyst 5000 family switches using MLS. Refer to the Layer 3 Switching Configuration Guide—Catalyst 5000 Family, 4000 Family, 2926G Series, 2926 Series, 2948G for MLS configuration procedures.
- If one MSFC fails in a system with redundant MSFCs, second hop routers could continue to send traffic to the failed MSFC for a period of time until the second hop router realizes that the MSFC is down.
- HSRP addresses only first hop redundancy; it ensures that the default gateway configured on the clients (workstations) remains up even if one router from the HSRP group goes down.
- HSRP ensures that traffic going from the client through the default gateway to the ultimate destination is supported with the loss of one MSFC.
- The HSRP MAC and IP addresses are never known to the other routers, which means that the reverse traffic from the destination to the originating client may or may not go through the same router. This is especially true if the source and destination are more than one hop away. The second hop router (from the client) will see that the client is reachable through both the MSFCs and through load balancing, could spread the reverse traffic between the two MSFCs.
- When one MSFC fails, the HSRP detects it fairly fast (10 seconds based on default HSRP settings), which means that traffic from the client to its destination goes through. However, the second hop router has to rely on the routing protocol's (RIP/OSPF) convergence time (from 30 to 90 seconds) to realize that one MSFC is down and will try to send the reverse traffic to the failed MSFC.
- In summary, the reverse traffic flow can happen through either MSFC if the source and destination are more than one hop away.
- NetFlow Data Export (NDE) version 7 is not supported for the MSFC.
- When using the Network Address Translation (NAT) router feature on the MSFC, packets traversing the NAT outside interface might, under certain configurations, be software routed instead of being shortcut, regardless of whether they should or should not be translated. Ideally, for packets traversing the NAT outside interface, you would want only those packets requiring NAT to be software routed. IOS in software will only translate traffic that is traversing from NAT inside to NAT outside interfaces and vice versa.
- By making the ACL used for NAT more specific it is possible to limit the software handled packets to only those requiring NAT translation.
- For example, if you use a general ACL (such as permit ip any any) to specify the traffic that requires NAT, then all traffic inbound or outbound on the NAT outside interface will be software routed (including traffic not originating or destined to NAT inside interfaces). If it is possible to use a more specific ACL (such as permit ip 10.1.1.0 0.0.0.255 any), then only the NAT outside traffic matching that ACL will be software routed. This traffic will still be software routed regardless of whether it is originating or destined to NAT inside interfaces. However, by making the ACL more specific, you can limit the amount of traffic that is software routed due to the NAT ACL.
- ACL configuration guidelines: When configuring ACLs on an interface with the configuration command tcam priority {high | low | normal}, entering high Ternary Content Addressable Memory (TCAM) priority gives ACLs on that interface priority for getting into the TCAM over ACLs of interfaces with lower (low or normal) priority.
- If the ACLs on an interface with high priority do not fit in the TCAM, the ACLs for interfaces of lower priority will not be inserted into the TCAM until it is possible to fit the high priority ACLs into the TCAM.
- You can configure VLAN access control lists (VACLs) on the switch to apply to all packets that are routed into or out of a VLAN, or are bridged within a VLAN. VACLs are strictly for security packet filtering and redirecting traffic to specific physical switch ports. Unlike IOS ACLs, VACLs are not defined by direction (input or output).
- Refer to the Catalyst 6000 Family Multilayer Switch Feature Card and Policy Feature Card Configuration Guide for detailed information.
- MAC address-based IOS ACLs are not supported for packets shortcut in hardware. MAC address-based IOS ACLs will be applied on software-switched packets. MAC address-based access control can be supported in hardware for non IP/IPX packets using VACLs. We recommend that you use VACLs to do MAC-addressed-based ACLs.
- Broadcast-to-multicast translation used in conjunction with the multicast helper command does not work if a flow is hardware switched.
- If TFTP downloads (net boots) are timing out, use the following IOS global configuration command for TFTP booting:
- ip tftp boot-interface tftp_interface
- where tftp_interface is the interface the TFTP boot server is on.
- If you enable multicast routing globally, then you should also enable multicast routing (using the ip pim command) on all Layer3 interfaces on which you anticipate receiving IP multicast traffic. This causes the packets to be sent to the process switching level for creating the route entry. However, if you disable multicast routing on the RPF interface, the entry cannot be created and the packet is dropped. Exceeding the source-traffic rate that can be handled by the process level can have an undesirable impact on the system. For instance, HSRP timers can expire on a standby router and cause HSRP flapping.
- Delivery acknowledgment timeouts might occur:
SCP-4-DACK_TIMEOUT_MSG:SCP delivery ack timeout for opcode=118
- When a delivery acknowledgment timeout occurs for opcode 118 (i.e multicast MLS SCP messages), then the impact depends on whether MMLS is in IDLE or ACTIVE state (can be determined by entering the show mls ip multicast statistics command). If MMLS is ACTIVE, the message is only a warning and can be ignored. If MMLS is IDLE, this message displays:
Multicast MLS is disabled due to internal messaging error
- The feature is disabled on the MSFC. You must disable and reenable the IGMP feature on the NMP before reenabling MMLS on the MSFC.
- After enabling PIM on an interface, you need to enter the ip mroute-cache command on the interface to enable multicast fast-switching. If you have "no ip mroute-cache" configured, multicast packets that are not hardware switched will go to process level which increases the load on the router. Software fast-switching is useful for flows that can only be partially hardware switched.
If you lose the boot loader image, please refer to the following link for boot loader image recovery procedures:
http://www.cisco.com/warp/customer/473/14.html
This section describes open and resolved caveats in Release 12.0(7)XE1 for the MSFC.
This section describes open caveats in Release 12.0(7)XE1.
- DLSw Ethernet redundancy is not supported. (CSCdp93599)
- All Layer 3 shortcuts are purged when the MSFC is added to or removed from a list of SPAN sources. This causes established flows to be sent to the routing software for forwarding.
- To honor the change in the SPAN configuration, the router software needs to flush the software cache entries on every interface. As a side effect, the Layer 3 table gets purged for each outgoing VLAN. This should only happen when the SPAN configuration changes and the MSFC gets added to or removed from a SPAN session in the ingress direction.
- Workaround: Use care when you choose to configure the MSFC as a SPAN source; we recommend that you do so during low traffic. (CSCdm83559)
- Entering the no ip routing command does not generate a purge request.
- The MSFC does not send a global purge request to the supervisor engine NMP the first time you enter the no ip routing command on the MSFC after a reload. IP traffic continues to be switched by the NMP even after the MSFC is configured with no ip routing.
- Workaround: Issuing the ip routing command followed by the no ip routing command a second time sends a global purge message to the NMP which purges shortcuts on the supervisor engine NMP. (CSCdm91663)
- When MSFCs are configured for multigroup HSRP, the ping success rate is 50 percent when CEF is enabled on the active MSFC. If CEF is disabled, the ping success rate is 100 percent but we do not recommend disabling CEF. This is an intermittent bug. (CSCdm68596)
- When a redundant MSFC comes up, an incorrect inventory message might be received after the Feature Manager is spawned. As a result, an incorrect module ID is used to communicate to the other MSFC. This is an intermittent bug. This problem corrects itself and the message can be ignored. (CSCdp56663)
This section describes resolved caveats in Release 12.0(7)XE1.
- Unicast and multicast IP packets may not get properly routed if a multicast boundary is applied to an interface. A workaround is to specify a "permit any any" ACE as the last statement of the ACL associated with the multicast boundary. Note that you cannot configure any other access-group on the interface on which a multicast boundary is configured. This problem is fixed in Release 12.0(7)XE1. (CSCdp22095)
- Occasionally, following an error that causes a reload, files in the MSFC bootflash:device are corrupted, which might make the MSFC unbootable. This problem is resolved in Release 12.0(7)XE1. (CSCdp53157)
- Occasionally, during a reload caused by an error, the attempt to write the crashinfo file may fail, which causes another reload. The second reload overwrites the crashinfo file from the original error. This problem is resolved in Release 12.0(7)XE1. (CSCdm79471)
Note Release 12.0(7)XE is deferred.
This section describes open and resolved caveats in Release 12.0(7)XE for the MSFC.
This section describes open caveats in Release 12.0(7)XE.
- DLSw Ethernet redundancy is not supported. (CSCdp93599)
- Unicast and multicast IP packets may not get properly routed if a multicast boundary is applied to an interface. A workaround is to specify a "permit any any" ACE as the last statement of the ACL associated with the multicast boundary. Note that you cannot configure any other access-group on the interface on which a multicast boundary is configured. This problem is fixed in Release 12.0(7)XE1. (CSCdp22095)
- All Layer 3 shortcuts are purged when the MSFC is added to or removed from a list of SPAN sources. This causes established flows to be sent to the routing software for forwarding.
- To honor the change in the SPAN configuration, the router software needs to flush the software cache entries on every interface. As a side effect, the Layer 3 table gets purged for each outgoing VLAN. This should only happen when the SPAN configuration changes and the MSFC gets added to or removed from a SPAN session in the ingress direction.
- Workaround: Use care when you choose to configure the MSFC as a SPAN source; we recommend that you do so during low traffic. (CSCdm83559)
- Entering the no ip routing command does not generate a purge request.
- The MSFC does not send a global purge request to the supervisor engine NMP the first time you enter the no ip routing command on the MSFC after a reload. IP traffic continues to be switched by the NMP even after the MSFC is configured with no ip routing.
- Workaround: Issuing the ip routing command followed by the no ip routing command a second time sends a global purge message to the NMP which purges shortcuts on the supervisor engine NMP. (CSCdm91663)
- When MSFCs are configured for multigroup HSRP, the ping success rate is 50 percent when CEF is enabled on the active MSFC. If CEF is disabled, the ping success rate is 100 percent but we do not recommend disabling CEF. This is an intermittent bug. (CSCdm68596)
- When a redundant MSFC comes up, an incorrect inventory message might be received after the Feature Manager is spawned. As a result, an incorrect module ID is used to communicate to the other MSFC. This is an intermittent bug. This problem corrects itself and the message can be ignored. (CSCdp56663)
None.
This section describes open and resolved caveats in Release 12.0(3)XE2 for the MSFC.
Note Release 12.0(3)XE2 is deferred.
This section describes open caveats in Release 12.0(3)XE2.
- DLSw Ethernet redundancy is not supported. (CSCdp93599)
- All Layer 3 shortcuts are purged when the MSFC is added to or removed from a list of SPAN sources. This causes established flows to be sent to the routing software for forwarding.
- To honor the change in the SPAN configuration, the router software needs to flush the software cache entries on every interface. As a side effect, the Layer 3 table gets purged for each outgoing VLAN. This should only happen when the SPAN configuration changes and the MSFC gets added to or removed from a SPAN session in the ingress direction.
- Workaround: Use care when you choose to configure the MSFC as a SPAN source; we recommend that you do so during low traffic. (CSCdm83559)
- The MSFC does not send a global purge request to the supervisor engine NMP the first time you enter the no ip routing command on the MSFC after a reload. IP traffic continues to be switched by the NMP even after the MSFC is configured with no ip routing.
- Workaround: Issuing the ip routing command followed by the no ip routing command a second time sends a global purge message to the NMP which purges shortcuts on the supervisor engine NMP. (CSCdm91663)
- When routers are configured for multigroup HSRP, intermittently the ping success rate is 50 percent when CEF is enabled on the active router. If CEF is disabled, the ping success rate is 100 percent. (CSCdm68596)
This section describes resolved caveats in Release 12.0(3)XE2.
- The default interface bandwidth is set incorrectly, resulting in the Catalyst 6000 switch not being properly selected in protocols such as EIGRP. This problem is resolved in Release 12.0(3)XE2. This problem is fixed in Release 12.0(3)XE2. (CSCdp01849)
- Under very heavy stress conditions, where the MSFC is receiving more data than it can handle, it was possible for an extremely low percentage of outgoing packets to be corrupted. This problem is resolved in Release 12.0(3)XE2. (CSCdm82298)
Note Release 12.0(3)XE1 is deferred.
This section describes open caveats in Release 12.0(3)XE1 for the MSFC.
- DLSw Ethernet redundancy is not supported. (CSCdp93599)
- All Layer 3 shortcuts are purged when the MSFC is added to or removed from a list of SPAN sources. This causes established flows to be sent to the routing software for forwarding.
- To honor the change in the SPAN configuration, the router software needs to flush the software cache entries on every interface. As a side effect, the Layer 3 table gets purged for each outgoing VLAN. This should only happen when the SPAN configuration changes and the MSFC gets added to or removed from a SPAN session in the ingress direction.
- Workaround: Use care when you choose to configure the MSFC as a SPAN source; we recommend that you do so during low traffic. (CSCdm83559)
- The MSFC does not send a global purge request to the supervisor engine NMP the first time you enter the no ip routing command on the MSFC after a reload. IP traffic continues to be switched by the NMP even after the MSFC is configured with no ip routing.
- Workaround: Issuing the ip routing command followed by the no ip routing command a second time sends a global purge message to the NMP which purges shortcuts on the supervisor engine NMP. (CSCdm91663)
- When routers are configured for multigroup HSRP, intermittently the ping success rate is 50 percent when CEF is enabled on the active router. If CEF is disabled, the ping success rate is 100 percent. (CSCdm68596)
For information on configuring MSFC and PFC features, refer to these publications:
- Catalyst 6000 Family Multilayer Switch Feature Card and Policy Feature Card Configuration Guide
- Catalyst 6000 Family Software Configuration Guide and the Catalyst 6000 Family Command Reference publication.
- For additional information on Cisco IOS commands, see the Configuration Fundamentals Command Reference publication.
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.
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.
Posted: Thu Sep 21 12:00:42 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
