|
Table Of Contents
Release Notes for Cisco ONS 15540 ESPx
for Cisco IOS Release 12.1(12c)EVDetermining the Software Version
New Features in Release 12.1(12c)EV
New Features in Release 12.1(10)EV3
New Features in Release 12.1(10)EV2
Obtaining Technical Assistance
Obtaining Additional Publications and Information
Release Notes for Cisco ONS 15540 ESPx
for Cisco IOS Release 12.1(12c)EV
This document describes caveats for Cisco IOS Release 12.1(12c)EV for the Cisco ONS 15540 ESPx.
Date: January 27, 2003
Text Part Number: OL-3404-03
Contents
This document includes the following information:
• Caveats
• Limitations and Restrictions
• Obtaining Technical Assistance
Introduction
The Cisco ONS 15540 ESPx is an optical transport platform that employs DWDM (dense wavelength division multiplexing) technology. With the Cisco ONS 15540 ESPx, users can take advantage of the availability of dark fiber to build a common infrastructure that supports data, SANs (storage area networks), and TDM (time-division multiplexing) traffic. The system uses an enhanced chassis with front fiber-optic cable access for optical interconnections between transponders and optical mux/demux modules. For more information about DWDM technology and applications, refer to the Introduction to DWDM Technology publication and the Cisco ONS 15540 ESPx Planning Guide.
System Requirements
This section describes the system requirements for Cisco IOS Release 12.1(12c)EV and includes the following sections:
• Determining the Software Version
Memory Requirements
The DRAM memory configuration is 128 MB, which is the default for the Cisco ONS 15540 ESPx.
Hardware Supported
Table 1 lists the hardware components supported on the Cisco ONS 15540 ESPx and the minimum software version required. See the "Determining the Software Version" section for information on determining your software version.
Determining the Software Version
Note We strongly recommend that you use the latest available software release for all Cisco ONS 15540 ESPx hardware.
To determine the version of Cisco IOS software currently running on a Cisco ONS 15540 ESPx system, log in to the system and enter the show version EXEC command.
Upgrading the System Image
To ensure proper system functioning, follow the system image upgrading procedure described in the Cisco ONS 15540 ESPx Software Upgrade Guide.
Note Always set the configuration register to 0x2102 when upgrading the system image using the config-reg 0x2102 command in configuration mode.
Caution Improper system image upgrades can affect system functioning and redundancy. Always follow the recommended upgrade procedures.
Feature Set Table
The Cisco IOS Release software is packaged in feature sets (also called software images) depending on the platform. Each feature set contains a specific set of Cisco IOS software features. Table 2 lists the Cisco IOS software feature sets available for the Cisco ONS 15540 ESPx.
Table 2 Feature Sets Supported by the Cisco ONS 15540 ESPx
Feature Set 12.1(12c)EV 12.1(10)EV3 12.1(10)EV2 12.1(10)EV1Gigabit Ethernet
X
X
X
X
Fast Ethernet
X
X
X
X
Ethernet
X
X
X
X
ATM OC-3/STM-1, OC-12/STM-4, and OC-48/STM-16
X
X
X
X
X
X
X
X
POS3
X
X
X
X
Fibre Channel (1 Gbps)
X
X
X
X
Fibre Channel (2 Gbps)
X
X
X
X
FDDI4
X
X
X
X
ESCON5 SM (200 Mbps)
X
X
X
X
FICON6 (800 Mbps)
X
X
X
X
Token Ring
X
X
X
X
SNMP
X
X
X
X
CiscoView
X
X
X
X
Cisco Transport Manager
X
X
X
X
CDP7
X
X
X
X
IP packets
X
X
X
X
OSCP8
X
X
X
X
APS9 protocol packets
X
X
X
X
Point-to-point
X
X
X
X
Hubbed ring
X
X
X
X
Meshed ring
X
X
X
X
IBM GDPS10 ETR/CL
X
X
X
X
IBM GDPS 10 coupling link
X
X
X
X
Unidirectional path switching
X
X
X
X
Bidirectional path switching
X
X
X
X
CDL over 10-GE
X
X
X
1 SONET = Synchronous Optical Networking
2 SDH = Synchronous Digital Hierarchy
3 POS = Packet over SONET
4 FDDI = Fiber Distributed Data Interface
5 ESCON = Enterprise Systems Connection
6 FICON = Fiber Connection
7 CDP = Cisco Discovery Protocol
8 OSCP = Optical Supervisory Channel Protocol
9 APS = Automatic Protection Switching
10 GDPS = Geographically Dispersed Parallel Sysplex
New and Changed Information
This section lists new features that appear in Cisco IOS Release 12.1.
New Features in Release 12.1(12c)EV
The following new feature is available for the Cisco ONS 15540 ESPx in Cisco IOS Release 12.1(12c)EV:
•The Cisco ONS 15540 Protection Switch Module (PSM) allows a customer to protect the entire fiber path by splitting an optical signal from one fiber trunk into two redundant fiber paths. This offers customers a cost-effective protection option and added protection against fiber cuts in the network.
New Features in Release 12.1(10)EV3
No new features are available for the Cisco ONS 15540 ESPx in Cisco IOS Release 12.1(10)EV3.
New Features in Release 12.1(10)EV2
The following new features are available for the Cisco ONS 15540 ESPx in Cisco IOS Release 12.1(10)EV2:
•Hardware:
–Non-protected dual subslot motherboard for Cisco ONS 15540 ESPx
–Splitter protected dual subslot motherboard for Cisco ONS 15540 ESPx
–10-GE transponder module
•Software:
–CDL over 10-GE
Caveats
This section lists the caveats and corrected caveats for each release. Use Table 3 to determine the status of a particular caveat. In the tables, "C" indicates a corrected caveat, and "O" indicates an open caveat.
This section describes the caveats in the Cisco ONS 15540 ESPx.
Symptom: Loss of signal might occur before SD (signal degrade) and SF (signal failure) thresholds are exceeded and traffic may still continue to pass transparently.
The loss of signal detection is taken from the OE (optical to electrical) conversion subsystem, which is different from the source of the SD and SF counters. The loss of light sensitivity is a characteristic of the OE conversion unit, and it may vary from unit to unit but is always < -30dBm.
Workaround: None.
Symptom: When the Rx port fiber is removed from the transponder module, ingress alarms are reported and cleared repeatedly. The alarm should not clear and the alarm should be reported only once.
Workaround: None
Symptom: Processor card gets into a nonresponsive state.
Workaround: None
Symptom: Processor card gets into a nonresponsive state for an extended interval, during which time the active standby LEDs may not indicate the correct active standby state.
Workaround: If the processor card has not been reset by the redundant processor card, the nonresponsive processor card can be removed and re-inserted in the chassis. This may cause a brief hit to data traffic, but the redundant processor card should take over and bring the system back up.
Symptom: The reprogram for the standby processor card fails.
Workaround: Run the reprogram on the active processor card, enable the processor switchover after switchover, and then run the reprogram on the new active processor card. Remove and reinsert the processor card for the new FPGA to become effective.
Symptom: The encapsulation fastethernet command fails on multimode transponders. The clock rate 100000 command succeeds but then pings over the signal fail intermittently.
Workaround: None.
Symptom: The show interface command output for a wave interface displays an "up" state, but the Signal Quality shows loss of sync.
Workaround: None.
Symptom: Multiple %METOPT-2-PORTFAIL messages are seen when using the y-cable aps configuration with single AFOV. However, this does not affect the functionality.
Workaround: None.
Symptom: CiscoView might display a different receive LED status on transponders from what is actually seen on the device.
Workaround: None.
Symptom: Client transmit enabled upon insertion disrupts y-cable clients.
Workaround: Remove client transmit fiber (y-cable leg) from the standby transponder before reinserting. Connect it back a few seconds after re-insertion of the standby transponder.
Symptom: The first time you OIR the OSC linecard, the card is brought into the admindown state.
Workaround: Enter the no shutdown command when the interface recovers.
Symptom: Topology Neighbour configuration is lost on mux-demux motherboard OIR.
Workaround:The topology neighbour is viewable after reconfiguring the wdm interface.
Symptom:Interface reports up/up even when there is no light source connected.
Workaround: Perform a shut and then a no shut on the interface.
Symptom: A transparent interface carrying Gigabit Ethernet traffic and configured with gigabit Fibre Channel encapsulation shows good quality signal on the show interfaces transparent command output and does not assert any ingress alarms. The wave interface assert loss of lock and loss of sync alarms.
Workaround: OIR the transponder will bring it to the correct state.
Symptom: The LoF alarms donot reassert inthe show facility-alarm status after shut/no shut.
Workaround:Disabling and reenabling the monitoring for the transparent interface will bring back the alarms.
Symptom: The show facility-alarm status does not report existing LoF/LoSync/LoLock alarms after
OIR/hw-mod power off/on.
Workaround: Disable and enable monitoring back reassert existing alarms in the show facility-alarm status.
Symptom: After removing and reinserting (OIR) of a transponder, the laser frequency is not programmed to the transponder correctly which results in a wavelength filter mismatch and the wavelength not coming out of the filter.
Workaround: Configure the Wave interface for the alternate frequency and then program it back to the desired frequency using the laser frequency <value in MHz> command.
Symptom: Line card function version in IOS should return the hex value.
Workaround: None.
Symptom: The processor card gets stuck in a nonresponsive state waiting for the console UART TxReady to get set. Normally a watchdog timeout will force recovery, but in some instances the Standby processor card does not recover on its own.
Workaround: Remove and replace the standby processor card.
Symptom: Under some situations the erratas of the system controller used on the processor card (GT64120A) can cause:
— A software forced crash due to memory ECC errors
— A bus error exception
— Corruption of data
Workaround: None.
Symptom: Processor card becomes nonresponsive and does not respond to an NMI.
Workaround: Update processor card image to version 1.25 or higher.
Symptom: A compatibility problem was detected in the released images that caused them to reject communication with the new images with a different cpu_red client version. This will cause the Active cpu to reset the Peer cpu.
Workaround: Since this problem comes into existance only if the cpu_red client version is different between 2 images, this problem doesn't exist in the old released images. Since the new images with the incremented cpu_red client version contains the fix for compatibility as well, this bug should not cause any impact in the field.
Symptom: CPU info showing up in sh hard, even after removing.
Workaround: None.
Symptom: If a Downlink Client interface is configured for CDL but is connected to a non-CDL device, the CDL message channel is down.
Workaround: Ensure Downlink Client interface is configured correctly.
Symptom: Under some circumstances, single bit ECC errors occur and are corrected by the system controller, but are not recorded; the user is unaware of these occurances.
Workaround: None.
Symptom: If a line card which was earlier removed or never inserted before switchover and if it gets inserted while a switchover is happening, then the line card and its interfaces may not come up properly.
Workaround: Re-insert line cardafter switchover is complete.
Symptom: The Cisco ONS 15540 might crash when using the is_optical_ifstatus_up command; this is an intermittent problem.
Workaround: None.
Symptom: In a configuration where a Cisco ONS 15540 ESPx has 10-GE downlinks to two Cisco ONS 15530 systems, the tengigethernetphy interface is administratively shut down and the ESCON ports associated with the first Cisco ONS 15530 are also downed. However, the ESCON ports connected to the second Cisco ONS 15530 are still up.
Workaround: Down the tengigethernetphy interface associated with the second Cisco ONS 15530.
Symptom: Following a CPU crash and switchover, if a show redundancy command is issued on the new Active CPU, it currently shows "Reported Switchover Reason" as "Not known". If a show version is issued on the Standby CPU that crashed, it shows additional troubleshooting information.
Workaround: None.
Symptom: A few kinds of software exceptions on the Active CPU can disable the ability for the standby CPU to reset the Active CPU if the Active CPU becomes non-responsive.
Workaround: None.
Symptom: getmany on ifMIB hangs in a loop.
Workaround: None.
Symptom:It takes about 15 minutes for a mode-mismatch event/trap to be set/generated after the mis-configuration that causes it is configured on the system.
Workaround: None.
Symptom: From snmp, ptopoConnEntry can be created with entPhysicalIndex, which does not correspond to any valid interface on the box.
Workaround: None.
Symptom: Configuring both line and trunk side loopback on the 10-GE trunk card affects the Traffic flow.
Workaround: Reconfigure the 10-GE trunk card with loopback on only line or trunk side, not both. OIR the 10-GE card to restore traffic.
Symptom: Incorrect OPM behavior.
Workaround: None.
Symptom: CDL hec counters are displayed in the show interface tengigethernetphy when CDL is disabled.
Workaround: None.
Symptom: Traffic is disrupted on bootup and switchover when the client side of the 10-GE trunk card has CDL disabled and both the client side and the trunk side are configured for cdl force hop
Workaround: Use the no cdl defect-indication force hop command on the client side.
Symptom: Unable to manage box configured with eigrp after a CPU switchover.
Workaround: Connect to the console port and remove passive-interface config in eigrp configuration.
Symptom:The DI error message does not indicate DI bit status.
Workaround: None.
Symptom: Line Laser Failure not reported in sh fac stat at TSP2 XCVR OIR.
Workaround: None.
Symptom: Some interfaces will not be available to the NMS station since the agent does not create them on OIR.
Workaround: Reload the box after removal/insertion of the cards.
Symptom: APS message channel configured for UDP/IP does not work over more than 2 IP hops. The UDP/IP packet gets dropped at the end of the second hop.
Workaround: None.
Symptom: Oir of SFA doesnt reflect correct patch status for pom & mux.
Workaround: None.
Symptom: Traceback @optical_idb_wave_ethernet_phy_report.
Workaround: None.
Symptom: Both active and standby lasers in a bidirectional y-cable APS configuration on modules in sub-slot 0 turn on erroneously.
Workaround: This bug has been fixed by using the correct format for programming the switchover-command register.
Symptom: The redundancy reload shelf command on the Active cpu can cause a switchover if the peer cpu is in Rommon.
Workaround: Use the reload command to reload the Active cpu, if the peer cpu is in Rommon.
Symptom: All interval entries of OPM are not returned by getnext.
Workaround: None.
Symptom: ciscoFlashDeviceChangeTrap should be supported on ONS155xx platforms since it is a basic operation. Whenever a removable flash device is removed/inserted, this trap should be generated.
Workaround:None.
Symptom: When forward laser control feature is enabled in hardware (either due to user configuration or due to Y-cable configuration), and the waveEthernet interface laser is shut by this safety feature, the laser soft-start procedure has to be followed when the laser is enabled again.
Workaround: None.
Symptom: The egress Loss of Signal alarm is not reasserted in the show facility status after hw-module power is turned off/on.
Workaround: None.
Symptom: The wave i/f remains down when the signal quality is GOOD and after the hw-module power off/on.
Workaround: None.
Symptom: The Rx Power display in some cases is off by +/-4dBm in comparision with the real reading using power meter.
Workaround: Use a calibrated transponder.
Symptom: The default laser frequencies of the transponders in 'odd' subslot (i. e. x/1 or x/3) are not restored correctly after the second OIR. The laser frequencies are stored correctly for the first OIR only.
For example, when inserting a transponder (channel n and channel n+1) to subslot x/1 the first time, the default laser frequency is n+1 (correct). Remove this transponder and insert another (channel m and channel m+1), the default laser frequency becomes m (incorrect; it should be m+1).
Workaround:OIR the linecard.
Symptom: False alarm LCMDC-3-OPT-SWITCH-FAIL while force APS switchover.
Workaround: None.
Symptom: Not obvious. The optical receive power level displayed on the show interface is not very accurate. It may be off as much as +/-4dBm in some cases but most of the cases it is OK.
Workaround: None.
Symptom: The wavepatches are stuck in the down state after using the sh/no sh of wave interface command with splitter APS after the trunk fiber has been cut.
Workaround: None.
Symptom:System crashes due to PCI Master abort while doing Sandisk OIR.
Workaround: None.
Symptom: The low warning threshold alarm is not cleared in the show facility command output.
Workaround: None.
Symptom: After a fiber cut, the OSC interface remains up with signal quality good.
Workaround: Use the shut/no shut command.
Symptom: For the sysplex protocol, the end-to-end FLC setting in the ctrl-mode is not correctly programmed after the OIR/FPGA reprogram.
Workaround: Using the no encap and encap sysplex etr commands on the transparent interface will program it correctly.
Symptom: When APS communication goes down, and an APS failure is subsequently detected, APS may switchover even though the communication is down. Based on this type of failure, there may be a unidirectional switchover. For IBM sysplex CLO/ETR applications, unidirectional switchover may lead to data corruption.
Workaround: None.
Symptom: In a point-to-point bidirectional situation, when the trunk Rx on both NEs are pulled and one of them is later replaced, APS may go back-and-forth between Working and Protection. The root cause is a hardware limitation consisting of no monitoring on the standby. As a result, the driver declares both Working and Protection as down when the wave interface goes down. In bidirectional APS this essentially means that the local side may inform the remote side that Working/Protection is down when it is not really down. APS has the ability to settle down on the good side, however, due to the bidirectional message (DO-NOT-REVERT in this case) from the far side; the local side switches away from the good side, and the cycle repeats. Note that this problem does not always happen, and requires certain timing in order for it happen.
Workaround:
1. Use force switch or lockout to peg the receive to the good side.
2. Temporarily change the direction from bidirectional to unidirectional. This however requires disabling the group.
Symptom: In bidirectional APS, if both NEs have the same priority request, the master/slave determination fails, leading to both claiming the control and resulting in not sending a REVERSE-REQUEST.
Workaround: None.
Symptom: In a pre-configured APS group (for the case when the interfaces don't exist), if the group is configured for revertive mode, it cannot be enabled.
Workaround: None.
Symptom: Attempting to read a flash card formatted on another system causes advisory messages to be continuously printed to the console.
Workaround:None.
Symptom: cpu crash after midnight with optical performance on when an interface capable of performance monitoring is un-shutdown.
Workaround:None.
Symptom: Both working and protection client tx active in y-cable aps.
Workaround:None.
Symptom: The hw-module power on/off command is not supported for 10G downlink cards on the Cisco ONS 15540.
Workaround: None.
Symptom: Data traffic hit during the CPU switchover when the splitter aps is configured.
Workaround: None.
Symptom:In 10G Y-cable bi-directional APS configuration, whenever there are lots of CVRD errors received on the standby trunk due to a bad signal,(but still signal quality is GOOD in "sh interface") all the four FDI-H/E, and BDI-H/E bits in the DECCSR register MIGHT get latched. Due to this, lots of interrupts would be generated and the console flooded with a similar message for that interface:
00:15:17: %APS-3-PORT_FAIL: External Port Fail On WaveEthernetPhy10/1
Workaround: Improve the quality of the signal by removing some attenuation and/or cleaning the optical connectors so that CVRD errors are not seen.
Symptom: Spurious memory access is seen on OIR of 10G downlink card.
Workaround: None.
Symptom:When an invalid channel number is detected by the OSCP client while it processes the client message received from peer, OSCP does not free the message buffer. This results in buffer starvation over a period of time and connectivity via Network Management interface and Back Plane ethernet(IPC and OSCP) interface are lost.
Workaround: None.
Symptom: The optical alarms are not asserted or cleared correctly when the wave is in the administrative down state.
Workaround: Use the shut/no shut command on the Active wavepatch; the no shut command on the wave will clear the false alarms.
Symptom: When Rx power is low, the alarm and warning are not asserted on the wavepatch interface after switchover, from active wavepatch to standby wavepatch.
Workaround: None.
Symptom: Continuous SRC poll failure after removing the calibrated transponder and inserting it back into the non-calibrated transponder/POM card.
Workaround: None.
Symptom: Using the no shut command on the tenGigEthernetPhy or waveethernetPhy interfaces (which is DOWN due to Loss of Lock) brings the interface state to UP, even though the Loss of Lock is still asserted.
Workaround: Use the sh/no sh command on the interface for it to show the DOWN state.
Symptom: Loss of Sync is not re-asserted on the tengigEthernetPhy interface after a shut/no shut command has been issued on the interface, or on an OIR of the 10G module.
Workaround: None.
Symptom: The EtherDcc interface for 10GE cards is not in the ADMIN DOWN state onthe initial OIR of the module.
Workaround: None.
Symptom: Threshold group line is missing in the show interfaces waveethernetphy command output.
Workaround: None.
Symptom: PSMs are incorrectly recognized as a mux/demux card with IOS images that do not support the PSM.
Workaround: Upgrade software to 12.1(12c)EV.
Symptom: The tengigEthernetPhy interface is getting BDIH while the in-band message channel is disabled.
Workaround: None.
Symptom: Traffic loss of 30-45 sec may occur when a y-cable APS configuration with protection switchover is used with the Catalyst 6000 family.
Workaround: Disable auto-negotiation and enable debounce timer with a 100-ms delay on Catalyst 6000 family using the set port debounce mod/port enable command.
Symptom: When y-cable APS is configured, shutting off the power to the transponder using the hw-module power off command brings the power back on again immediately.
Workaround: Remove the APS configuration and perform power off.
Symptom: APS switchover time (50 ms) is not guaranteed for loss of lock, loss of sync, or loss of frame.
Workaround: None.
Symptom: The output of the show waveethernetphy interface command sometimes shows a high receive power value when there is no input signal connected to the card.
Workaround: OIR the card.
Symptom: Could not get a wave interface power reading graph with CiscoView 2.0/2.1 for an uncalibrated transponder.
Workaround:Use a calibrated transponder.
Symptom: When the 10-GE trunk (waveethernetphy) laser is down due to the FLC (forward laser control action), removing the FLC configuration does not turn back the laser on.
Workaround: None.
Limitations and Restrictions
This section provides limitations and restrictions for Cisco ONS 15540 ESPx hardware and software.
Transponder Modules
This section contains limitiations and restrictions that apply to transponder modules.
•When you insert the standby transponder module in a y-cable protected configuration, remove the cable from the transponder module before inserting the transponder module into the shelf. Failure to remove the cable might result in errors that can affect the performance of the active signal received by the client equipment.
•CRC errors occur with 2-Gbps Fibre Channel on single-mode transponders when high input power levels are received from the client laser sources.
Data errors or link-down conditions for 2-Gbps Fibre Channel might occur on single-mode transponders when used with certain client laser sources. Transmitters in some client GBIC and SFP transceiver units might send large overshoots in optical power with signal bit transitions, causing momentary overload conditions on the transponder client side receiver. The average transmitted power level from the GBIC does not violate the overload specification of the transponder client side receiver, so a power meter does not detect the overload.
The workaround is to attenuate the signal from the client equipment to a recommended level of -12 dBm when transmitting 2-Gbps Fibre Channel services.
•If both processor cards are removed, traffic through the system is affected as follows:
–For Type 2 extended range transponder modules, traffic is shut down.
–For 10-GE transponder modules, traffic is shut down.
–Type 1 SM transponder modules and MM transponder modules do not operate reliably. The traffic might be affected.
–In the shutdown state, the Status LED on the line card motherboard turns orange.
Note Traffic on pass through optical channels (which passively pass through the mux/demux modules) are not affected by the removal of the processor cards.
Related Documentation
Refer to the following documents for more information about the Cisco ONS 15540 ESPx:
• Regulatory Compliance and Safety Information for the Cisco ONS 15500 Series
• Cisco ONS 15540 ESPx Planning Guide
• Cisco ONS 15540 ESPx Hardware Installation Guide
•Cisco ONS 15540 ESPx Optical Transport Turn-Up and Test Guide
• Cisco ONS 15540 ESPx Cleaning Procedures for Fiber Optic Connections
• Cisco ONS 15540 ESPx Configuration Guide
• Cisco ONS 15540 ESPx Command Reference
• Cisco ONS 15540 ESPx System Alarms and Error Messages
• Cisco ONS 15540 ESPx Troubleshooting Guide
• Network Management for the Cisco ONS 15540 ESPx
• Cisco ONS 15540 ESPx TL1 Commands
•MIB Quick Reference for the Cisco ONS 15500 Series
•Cisco ONS 15540 ESPx Software Upgrade Guide
Obtaining Documentation
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation on the World Wide Web at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
International Cisco web sites can be accessed from this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Registered Cisco.com users can order the Documentation CD-ROM (product number DOC-CONDOCCD=) through the online Subscription Store:
http://www.cisco.com/go/subscription
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:
http://www.cisco.com/en/US/partner/ordering/index.shtml
•Registered Cisco.com users can order the Documentation CD-ROM (Customer Order Number DOC-CONDOCCD=) through the online Subscription Store:
http://www.cisco.com/go/subscription
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.
You can e-mail your comments to bug-doc@cisco.com.
You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) Website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.
Cisco.com
Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com provides a broad range of features and services to help you with these tasks:
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
To obtain customized information and service, you can self-register on Cisco.com at this URL:
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The avenue of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.
We categorize Cisco TAC inquiries according to urgency:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Cisco TAC Website
You can use the Cisco TAC website to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC website, go to this URL:
All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:
http://tools.cisco.com/RPF/register/register.do
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:
http://www.cisco.com/en/US/support/index.html
If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC website so that you can describe the situation in your own words and attach any necessary files.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•The Cisco Product Catalog describes the networking products offered by Cisco Systems as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
http://www.cisco.com/en/US/products/products_catalog_links_launch.html
•Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
•Packet magazine is the Cisco monthly periodical that provides industry professionals with the latest information about the field of networking. You can access Packet magazine at this URL:
http://www.cisco.com/en/US/about/ac123/ac114/about_cisco_packet_magazine.html
•iQ Magazine is the Cisco monthly periodical that provides business leaders and decision makers with the latest information about the networking industry. You can access iQ Magazine at this URL:
http://business.cisco.com/prod/tree.taf%3fasset_id=44699&public_view=true&kbns=1.html
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in the design, development, and operation of public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html
•Training—Cisco offers world-class networking training, with current offerings in network training listed at this URL:
http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Copyright © 2003 Cisco Systems, Inc. All rights reserved.
Posted: Wed Nov 3 16:31:31 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.