Table Of Contents
Release Notes for Cisco iSCSI Driver Version 3.1.1 for Linux
May 30, 2003
Note You can find the most current documentation on Cisco.com. This set of electronic documents may contain updates and modifications made after the hard-copy documents were printed.
These release notes support Cisco iSCSI Driver version 3.1.1 for Linux.
For a list of software caveats that apply to version 3.1.1, see the "Caveats" section. The caveats are updated for every maintenance version and are located on Cisco.com and the Documentation CD-ROM.
These Release Notes describe the following topics:
The Cisco iSCSI Driver for Linux provides an IP host with the ability to access storage through an IP network. The iSCSI driver uses the iSCSI protocol to transport SCSI requests and responses over an IP network between the IP host and a Cisco SN 5400 or MDS 9000 Series system.
Architecturally, the iSCSI driver combines with the IP host's TCP/IP stack, network drivers, and network interface cards (NICs) to provide the same functions as a SCSI or Fibre Channel adapter driver with a host bus adapter (HBA).
The iSCSI driver provides a transport for SCSI requests and responses for storage devices; however, instead of providing a transport for directly attached devices, the driver transports the SCSI requests and responses between the IP host and a Cisco SN 5400 or MDS 9000 Series system via an IP network. The SN 5400 or MDS 9000 Series system, in turn, transports SCSI requests and responses between it and the storage devices attached to it.
Once the iSCSI driver is installed and started, the host proceeds with a discovery process for storage devices.
A more technical description of the driver's design and its features can be found in the readme file that accompanies the iSCSI driver in the downloaded driver archive file.
Note The iSCSI protocol is an IETF-defined protocol for IP storage (ips). For more information about the iSCSI protocol, refer to the IETF standards for IP storage at http://www.ietf.org.
This section describes the system requirements for version 3.1.1 and includes the following information:
Operating System Requirements
•This driver requires a Linux kernel version 2.4.16 or later, running on an Intel IA32 (80386, 80486, Pentium) or equivalent, processor. Compilation requires that the kernel header files match the kernel version you want to use the driver with. Once compiled, the objects and executables can be moved to another host running the same level of the operating system.
•If you are running a kernel binary compiled for you by a Linux vendor, the iSCSI driver must be compiled against the source code distributed by the Linux vendor, without any modifications. The process of compiling a custom kernel from source makes modifications to the files in the kernel source tree, and an iSCSI driver compiled against a modified kernel source tree may not run on a kernel binary distributed by the Linux vendor.
If you have already made changes to the kernel source tree and you wish to run the iSCSI driver on one of the vendor's kernel binaries, you will need to reinstall the kernel source code provided by the Linux vendor.
•The iSCSI Driver for Linux supports single and multiprocessor systems.
•To ensure the best performance for iSCSI drivers, the extended windowing feature of TCP should be enabled on all IP hosts connecting to the SN 5400 Series system. In general, a larger window size enhances SN 5400 Series system performance.
•The receive and transmit flow control feature of the Gigabit Ethernet driver should be enabled on all IP hosts connecting to the SN 5400 Series system.
•If you are using a 3Com Gigabit Ethernet Server network interface card, the minimum supported revision level is "B" (3C985B-SX). Using a card with a lower revision level will decrease performance.
•Linux kernels released after January 11, 2003 may or may not work with this driver, depending on what changes have been made to the kernel's SCSI midlayer code. See the "Important Notes" section for additional information about known problems with Linux kernel code.
Note Additional information about Linux kernel issues can be found in the Linux Kernel HOWTO document at http://www.linux.org/docs/.
Linux assigns SCSI device nodes dynamically whenever a SCSI logical unit is detected. Variations in process scheduling and network delay may result in iSCSI targets being mapped to different SCSI device nodes (e.g /dev/sda, /dev/sdb) every time the driver is started. Because of this variability, configuring applications or operating system utilities to use the standard SCSI device nodes to access iSCSI devices may result in SCSI commands being sent to the wrong target or logical unit.
To provide a more reliable namespace, the iSCSI driver scans the system to determine the mapping from SCSI device nodes to iSCSI targets, and then creates a tree of directories and symbolic links under /dev/iscsi to make it easier to use a particular iSCSI target's logical units.
Under /dev/iscsi, there is a directory tree containing subdirectories for each iSCSI bus number, each target ID number on the bus, and each logical unit number for each target. For example, the whole disk device for bus 0, target ID 0, LUN 0 would be /dev/iscsi/bus0/target0/lun0/disk.
In each logical unit directory there is a symbolic link for each SCSI device node that may be connected to that particular logical unit. The symbolic links are modeled after the Linux device naming convention.
•The symbolic link disk maps to the whole-disk SCSI device node (e.g. /dev/sda, /dev/sdb, etc.).
•The symbolic links part1 through part15 map to each partition of that SCSI disk (e.g. /dev/sda1, dev/sda15, etc.).
Note These links will exists regardless of the number of disk partitions. Opening the partition devices will result in an error if the partition does not actually exist on the disk.
•The symbolic link mt maps to the auto-rewind SCSI tape device node for this LUN (e.g. /dev/st0), if any.
•Additional links for mtl, mtm and mta map to the other auto-rewind devices (e.g. /dev/st0l, /dev/st0m, /dev/st0a), regardless of whether these device nodes actually exist or can be opened.
•The symbolic link mtn maps to the no-rewind SCSI tape device node for this LUN (e.g. /dev/nst0), if any.
•Additional links for mtln, mtmn and mtan map to the other no-rewind devices (e.g. /dev/nst0l, /dev/nst0m, /dev/nst0a), regardless of whether those device nodes actually exist or can be opened.
•The symbolic link cd maps to the SCSI CD-ROM device node for this LUN (e.g. /dev/scd0), if any.
•The symbolic link generic maps to the SCSI generic device node for this LUN (e.g. /dev/sg0), if any.
Note Because the symlink creation process must open all of the SCSI device nodes in /dev in order to determine which nodes map to iSCSI devices, many modprobe messages may be logged to syslog. The messages indicate that modprobe could not find a driver for a specific combination of major and minor numbers. These are normal messages that occur when Linux is unable to find a driver to associate with a SCSI device node that the iSCSI daemon is opening as part of the symlink creation process, and can be ignored.
The iSCSI driver automatically maintains a bindings file (/var/iscsi/bindings). This file contains persistent bindings to ensure that the same iSCSI bus and target ID number are used for every iSCSI session to a particular iSCSI TargetName, no matter how many times the driver is restarted.This feature ensures that the SCSI numbers in the device symlinks described above will always map to the same iSCSI target.
See the readme file for additional information about target bindings and the bindings file.
Do not add mount entries for iSCSI devices to /etc/fstab because the Linux boot process normally mounts filesystems listed in /etc/fstab before the network is configured. The script "iscsi-mountall" will manage the checking and mounting of devices listed in the file /etc/fstab.iscsi, which has the same format as /etc/fstab. This script is automatically invoked by the iSCSI startup script.
To avoid the configuration problems associated with device name changes resulting from configuration changes and the variability of mapping between SCSI device nodes and iSCSI targets, mount the /dev/iscsi tree symlinks, use filesystem UUIDs or labels (see man pages for mke2fs, mount, and fstab) or logical volume management (see Linux LVM).
Note The iscsi-mountall script may timeout and fail to mount one or more filesystems if one or more iSCSI sessions are unable to login immediately due to network or authentication problems.
It is very important to unmount all filesystems on iSCSI devices before the iSCSI driver stops. If the iSCSI driver stops while iSCSI devices are mounted, buffered writes may not be committed to disk and filesystem corruption can occur.
Since Linux will not unmount filesystems that are being used by a running process, before iSCSI devices can be unmounted, any processes using those devices must be stopped.
To avoid filesystem corruption, the iSCSI shutdown script will automatically kill all processes using devices in /etc/fstab.iscsi, first by sending them SIGTERM, and then by sending any remaining processes SIGKILL. It will then unmount all iSCSI filesystems and kill the iSCSI daemon, terminating all connections to iSCSI devices.
Caution Filesystems not listed in /etc/fstab.iscsi may not be automatically unmounted.
Dynamic Target and LUN Discovery
To force the Cisco iSCSI driver for Linux to rediscover iSCSI devices and probe for LUNs, run /etc/rc.d/init.d/iscsi reload. This forces the iSCSI daemon to restart all iSCSI discovery processes and probe LUNs on all iSCSI targets.
See the readme file for additional information about dynamic target and LUN discovery.
Using Multipath I/O Drivers
If you are using a multipath I/O driver, you can adjust several iSCSI driver configuration parameters to improve performance in the multipath environments.
•The MaxDiskCommandTimeout value specifies how many seconds before a disk command is failed out of the iSCSI driver. In a multipath environment, the MaxDiskCommandTimeout value can be set to a small number, such as 5 or 10 seconds. This allows SCSI commands to an unreachable or unresponsive device to fail quickly, triggering the multipath driver to try another path to the storage device.
•The SessionReplacementTimeout value specifies how many seconds the driver should wait for a replacement iSCSI session to be established following a session drop. This timeout is primarily intended to help multipath I/O drivers detect network problems and switch to alternate paths, if available. In a multipath environment, the SessionReplacementTimeout value can be set to a small number, such as 10 or 30 seconds. This allows SCSI commands to fail quickly when an iSCSI network connection drops, triggering the multipath driver to try another path to the storage device.
See the readme file for additional information about using the iSCSI driver in a multipath environment.
SN 5400 Series System Software Requirements
The iSCSI Driver version 3.1.1 for Linux is interoperable with a Cisco SN 5400 Series system running software release 3.2.1 or later. This version of the driver is not interoperable with a Cisco SN 5400 Series system running software release 2.5.x or earlier.
MDS 9000 Series System Software Requirements
The iSCSI Driver version 3.1.1 for Linux is interoperable with a Cisco MDS 9000 Series system running SAN-OS Release 1.1(1) or later.
New and Changed Information
•The iSCSI driver version 3.1.1 iSCSI specification compliance has been upgraded to RFC.
•The iSCSI driver version 3.1.1 includes data and header digest support, configurable on either a per-target or global basis.
•The iSCSI driver interoperates with Cisco MDS 9000 Series systems.
See the readme file for additional information about all new features.
This section describes how to obtain iSCSI driver software and upgrade an existing iSCSI driver installation, and includes the following information:
Obtaining the iSCSI Driver and Updated SN 5400 Series System Software
Registered Cisco.com users can download the most current SN 5400 Series system software, Cisco iSCSI drivers, readme files, release notes and example configuration files from Cisco.com. In addition, information about driver compatibility and other relevant driver information is available on Cisco.com. You can access software and related information by following these instructions:
Step 1 At http://www.cisco.com, log in to Cisco.com. Click Technical Support and Software Center.
Step 2 At the Software Center web page, under Software Products & Downloads, click Storage Networking Software.
Step 3 At the Storage Networking Software web page, click the appropriate link for your software.
Step 4 At the Software Download web page, click the file that you want to download.Another software download web page will be displayed with detailed information about the download file and Cisco's Software License Agreement. Follow the instructions on that and any subsequent web pages to download the software.
Step 5 To install and configure storage router software, see the appropriate storage router software configuration guide and release notes. To install and configure an iSCSI driver, see the readme file that accompanies the iSCSI driver (in the downloaded driver archive file) and the appropriate release notes.
Configuration guides and release notes are available online. You can access online documentation by following these instructions:
Step 1 At http://www.cisco.com, click Products & Services and Storage Networking Products.
Step 2 At the Cisco Storage Networking Products web page, click Cisco SN 5400 Series Storage Routers.
Step 3 At the Cisco SN 5400 Series Storage Routers web page, click Technical Documentation. On the Technical Documentation web page, choose the appropriate link for documentation, release notes, or other related information.
Determining the iSCSI Driver Version
The directory /proc/scsi/iscsi contains a special file that can be used to get iSCSI driver version information, and the status from your iSCSI HBA. The name of the file is the iSCSI HBA host number, which is assigned to the driver by Linux.
When the file is read, it shows the driver version number, followed by a list all iSCSI targets and LUNs that the driver has found and can use.
Installing iSCSI Driver Software
Refer to the readme file that accompanies the iSCSI driver (in the downloaded driver archive file) for complete installation and configuration procedures.
Upgrading to a New Version
To upgrade to a new version of iSCSI driver software, follow these instructions:
Step 1 Unmount all iSCSI file systems and stop the old iSCSI driver. For example, to manually stop the iSCSI version 2.1.2 driver that was installed in the default directory, enter:/etc/rc.d/init.d/iscsi stop
Step 2 Remove the current iSCSI driver. Change to the directory containing the current iSCSI driver and issue the make remove command. You must have super-user (root) authority to remove the driver. For example:cd /usr/src/linux-iscsi-2.1.2make remove
This deletes the appropriate files from /lib/modules and /usr/local/sbin directories. The configuration files in /etc are not deleted.
Step 3 Follow the instructions in the readme file to install the new iSCSI driver software package.
See the readme file for additional information about installing iSCSI driver software.
Uninstalling iSCSI Driver Software
To uninstall the iSCSI driver software, follow these instructions:
Step 1 Change to the linux-iscsi-<version> directory. The <version> is the three digit version. For example:cd /usr/src/linux-iscsi-3.1.1
Step 2 Remove the iSCSI driver. You must have super-user (root) authority to remove the driver. For example:make remove
This deletes the appropriate files from /lib/modules and /usr/local/sbin directories. The configuration files in /etc are not deleted, since they will be needed if another driver is installed at a later time.
Step 3 Back up one directory and delete the source code. For example:cd ..rm -fr linux-iscsi-3.1.1
Upgrading the Linux Kernel
Because the Cisco iSCSI driver for Linux contains a Linux kernel module, the iSCSI driver must be rebuilt and reinstalled if you make any changes to the Linux kernel.
To remove, rebuild and reinstall the iSCSI driver for Linux, follow these instructions:
Step 1 Log in with super-user (root) authority, and change to the linux-iscsi-<version> directory. The <version> is the three digit version. For example:cd /usr/src/linux-iscsi-2.1.2
Step 2 Remove the iSCSI driver. For example:make remove
Step 3 Rebuild the iSCSI driver. For example:make cleanmake
Step 4 Reinstall the iSCSI driver. For example:make install
Because some Linux distributions include versions of this driver in their kernel source tree, recompiling the kernel source tree may create an older version of the iSCSI kernel module. The driver will fail to operate correctly if there is a version mismatch between the iSCSI daemon and the iSCSI kernel module.
If your kernel source tree already contains a version of this driver different from the one you have installed, you must disable the iSCSI driver in your kernel configuration before recompiling a new kernel from source. Leaving the iSCSI driver enabled in the kernel configuration during a kernel rebuild may result in a newer iSCSI kernel module being replaced by an older version from the kernel source tree.
Limitations and Restrictions
The Cisco iSCSI driver for Linux no longer supports a Linux kernel version 2.2.x. The iSCSI driver requires a 2.4.x Linux kernel version.
As of 11 January, 2003 there are several issues with the Linux kernel code that can cause problems when using SCSI devices (including iSCSI devices). Linux kernels released after this date may or may not have fixed these problems.
•All Linux kernels released on or before February 4, 2002 have a known flaw in the buffer and page cache design. When any writes to a buffered block device fail, it is possible for the unwritten data to be discarded from the caches, even though the data was never written to disk. Any future reads will get the prior contents of the disk, and it is possible for applications to get no errors reported.
This occurs because block I/O write failures from the buffer cache simply mark the buffer invalid when the write fails. This leaves the buffer marked clean and invalid, and it may be discarded from the cache at any time. Any future read either finds no existing buffer or finds the invalid buffer, so the read will fetch old data from disk and place it in the cache.
If the fsync(2) function initiated the write, an error may be returned. If memory pressure on the cache initiated the write, the unwritten buffer may be discarded before fsync(2) is ever called, and in that case fsync will be unaware of the data loss and will incorrectly report success.
There is currently no reliable way for an application to ensure that data written to buffered block devices has actually been written to disk. Buffered data may be lost whenever a buffered block I/O device fails a write.
The iSCSI driver attempts to avoid this problem by retrying disk commands for many kinds of failures. The MinDiskCommandTimeout defaults to infinite, allowing commands to be retried forever if the storage device is unreachable or unresponsive.
•The Red Hat Advanced Server 2.1 kernels released as of January 29, 2003 have a kernel bug that can cause unmount to oops. See bugs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74054 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66251 for more details. Please contact Red Hat and request a kernel update if you encounter this problem.
•All Linux kernels up to and including 2.4.20 have a bug in the SCSI device initialization code. If kernel memory is low, the initialization code can fail to allocate command blocks needed for proper operation, but will do nothing to prevent I/O from being queued to the non-functional device. If a process queues an I/O request to a SCSI device that has no command blocks allocated, that process will block forever in the kernel, never exiting and ignoring all signals sent to it while blocked.
If the LUN probes initiated by the iSCSI driver are blocked forever by this problem, it will not be possible to stop or unload the iSCSI driver, since the driver code will still be in use. In addition, any other LUN probes initiated by the iSCSI driver will also block, since any other probes will block waiting for the probe currently in progress to finish.
When the failure to allocate command blocks occurs, the kernel will log a message similar to the following:kernel: scsi_build_commandblocks: want=12, space for=0 blocks
In some cases, the following message will also be logged:kernel: scan_scsis: DANGER, no command blocks
•Linux kernels 2.2.16 through 2.2.20 and 2.4.0 through 2.4.18 are known to have a problem in the SCSI error recovery process. In some cases, a successful device reset may be ignored and the SCSI layer will continue on to the later stages of the error recovery process.
The problem occurs when multiple SCSI commands for a particular device are queued in the low-level SCSI driver when a device reset occurs. Even if the low-level driver correctly reports that all the commands for the device have been completed by the reset, Linux will assume only one command has been completed and continue the error recovery process. (If only one command has timed out or failed, Linux will correctly terminate the error recovery process following the device reset.)
This action is undesirable because the later states of error recovery may send other types of resets, which can affect other SCSI initiators using the target or other targets on the same bus. It is also undesirable because there are more serious bugs in the later stages of the Linux SCSI error recovery process.
The Linux iSCSI driver now attempts to avoid this problem by replacing the usual error recovery handler for SCSI commands that timeout or fail.
•Linux kernels 2.2.16 through 2.2.20 and 2.4.0 through 2.4.2 may take SCSI devices offline after Linux issues a reset as part of the error recovery process. Taking a device offline causes all I/O to the device to fail until the HBA driver is reloaded.
After the error recovery process does a reset, it sends a SCSI Test Unit Ready command to check if the SCSI target is operational again. If this command returns SCSI sense data, instead of correctly retrying the command, Linux will treat it as a fatal error and immediate take the SCSI device offline.
The Test Unit Ready will almost always be returned with sense data because most targets return a deferred error in the sense data of the first command received after a reset. This is a way of telling the initiator that a reset has occurred. Therefore, the affected Linux kernel versions almost always take the SCSI device offline after a reset occurs.
This bug is fixed in Linux kernels 2.4.3 and later.
The Linux iSCSI driver now attempts to avoid this problem by replacing the usual error recovery handler for SCSI commands that timeout or fail.
•Linux kernels 2.2.16 through 2.2.21 and 2.4.0 through 2.4.20 appear to have problems when SCSI commands to disk devices are completed with a check condition/unit attention containing deferred sense data. This can result in applications receiving I/O errors, short reads or short writes.
The Linux SCSI code may deal with the error by giving up reading or writing the first buffer head of a command, and retrying the remainder of the I/O.
The Linux iSCSI driver attempts to avoid this problem by translating deferred sense data to current sense data for commands sent to disk devices.
•Linux kernel 2.2.16 through 2.2.21 and 2.4.0 through 2.4.20 may crash on a NULL pointer if a SCSI device is taken offline while one of the Linux kernel I/O daemons (e.g. kpiod, kflushd, etc.) is trying to do I/O to the SCSI device. The exact cause of this problem is still being investigated.
Note Some of the other bugs in the Linux kernel error recovery handling may result in a SCSI device being taken offline, thus triggering this bug and resulting in a Linux kernel crash.
•Linux kernels 2.2.16 through 2.2.21 running on uniprocessors may hang if a SCSI disk device node is opened while the Linux SCSI device structure for that node is still being initialized.
This occurs because the sd driver which controls SCSI disks will loop forever waiting for a device busy flag to be cleared at a certain point in the open routine for the disk device. Because this particular loop will never yield control of the processor, the process initializing the SCSI disk device is not allowed to run, and the initialization process can never clear the device busy flag which the sd driver is constantly checking.
A similar problem exists in the SCSI generic driver in some 2.4 kernel versions. The sg driver may crash on a bad pointer if a /dev/sg* device is opened while it is being initialized.
Caveats describe unexpected behavior or defects in iSCSI software versions. Severity 1 caveats are the most serious caveats; severity 2 caveats are less serious.
This document describes open and resolved severity 1 and 2 caveats and selected caveats of other severities:
•The "Open Caveats" section lists open caveats that apply to the current version and may apply to previous versions.
•The "Resolved Caveats" section list caveats resolved in this version, but open in previous versions.
Within the sections, the caveats are sorted alphanumerically by caveat number.
Note If you have an account with Cisco.com, you can use Bug Navigator II to find caveats of any severity for any version. You can reach Bug Navigator II on Cisco.com at Service & Support:
When running Red Hat Advanced Server 2.1, the traffic unexpectedly stops and the Linux host is unavailable. The Red Hat Advanced Server 2.1 kernels released as of January 29, 2003 have a kernel bug that can cause unmount to oops. See bugs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74054 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66251 for more details.
Workaround: Avoid unmounting a filesystem while other heavy I/O is occurring. Please contact Red Hat and request a kernel update if you encounter this problem.
SMP systems can deadlock the iSCSI driver. If the driver receives multiple Async events on long-lived discovery sessions indicating new targets are available in rapid succession, the driver may deadlock on SMP systems.
Async events are generated by a Cisco SN 5400 Series system whenever the access list associated with a target is changed. For example, issuing the following CLI command will generate one event for each target that exists on the SCSI routing instance named sr1:[SN5428A] scsirouter sr1 target all accesslist any
Workaround: Change target access list associations one target at a time, and execute the commands slowly, or upgrade to the iSCSI driver for Linux, version 3.1.1.
The following sections describe the related documentation available for the iSCSI Driver version 3.1.1 for Linux, and the Cisco SN 5400 and MDS 9000 Series systems. These documents consist of the iSCSI driver release notes and readme file, and the SN 5400 and MDS 9000 Series system hardware installation and software configuration guides.
The SN 5400 and MDS 9000 Series system hardware installation and software configuration documentation sets are available as printed manuals or electronic documents. The iSCSI driver readme file is available in electronic format, as part of the software download package. See the "Obtaining the iSCSI Driver and Updated SN 5400 Series System Software" section for details.
This Release Notes document is the only document specific to iSCSI Driver version 3.1.1 for Linux. It is located on Cisco.com and the Documentation CD-ROM.
Each release of SN 5400 and MDS 9000 Series system software includes an associated Release Notes document, which is also available as an electronic document on Cisco.com and the Documentation CD-ROM.
Refer to the appropriate SN 5400 or MDS 9000 Series system hardware installation guide for hardware installation procedures. The Cisco SN 5428 Storage Router Hardware Installation Guide provides hardware installation procedures for SN 5428 Storage Routers. The Cisco SN 5428-2 Storage Router Hardware Installation Guide provides hardware installation procedures for SN 5428-2 Storage Routers. These documents are available as printed manuals. They are also available as electronic documents on Cisco.com and the Documentation CD-ROM
Refer to the appropriate SN 5400 or MDS 9000 Series system software configuration guide for software configuration information. The Cisco SN 5428 Storage Router Software Configuration Guide Release 3.2 provides configuration information for SN 5428 Storage Routers. The Cisco SN 5428-2 Storage Router Software Configuration Guide Release 3.2 provides configuration information for SN 5428-2 Storage Routers. These documents are available as printed manuals. They are also available as electronic documents on Cisco.com and the Documentation CD-ROM.
For documentation on the SN 5400 Series system web-based GUI, refer to the SN 5400 Series system web-based GUI online Help system.
Service and Support
For service and support for a product purchased from a reseller, contact the reseller, who offers a wide variety of Cisco service and support programs described in "Service and Support" of Cisco Information Packet shipped with your product.
Note If you purchased your product from a reseller, you can access Cisco.com as a guest. Cisco.com is Cisco Systems' primary real-time support channel. Your reseller offers programs that include direct access to Cisco.com services.
For service and support for a product purchased directly from Cisco, use Cisco.com.
Software Configuration Tips on the Cisco TAC Home Page
A variety of Cisco SN 5400 Series system software and iSCSI driver installation, configuration and usage tips are available on the Cisco Technical Assistance Center (TAC) Web Site.
You can access "tech tips" by following these instructions:
Step 1 At http://www.cisco.com, log in to Cisco.com. Click Technical Support, and select Hardware Support from the menu.
Step 2 At the Hardware Support web page, click Storage Networking Devices from the Hardware Support menu on the left side of the page.
Step 3 At the Storage Networking Devices web page, click the appropriate link for your system. For example, click the SN 5428 Storage Routers link.
Step 4 Click the Troubleshooting link, and then click the appropriate links for information about installing, configuring, and troubleshooting SN 5400 Series system software and iSCSI drivers.
Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at this URL:
You can access the Cisco website at this URL:
International Cisco web sites can be accessed from this URL:
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:
You can find instructions for ordering documentation at this URL:
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:
•Registered Cisco.com users can order the Documentation CD-ROM (Customer Order Number DOC-CONDOCCD=) through the online Subscription Store:
•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).
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.
You can email your comments to email@example.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:
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We 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 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:
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:
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:
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:
•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:
•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:
•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:
•Training—Cisco offers world-class networking training, with current offerings in network training listed at this URL:
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.