{{Note| You should avoid using PCs that have IP addresses randomly assigned to them by DHCP. The switch continues to use the old IP address unless you manually change it; however the Device Manager prompts you if it does detect this situation. UNIX workstations have a built-in syslog server. You must have root access (or run the Cisco syslog server as setuid to root) to stop the built-in syslog daemon and start the Cisco syslog server.}}

{{Note| You should avoid using PCs that have IP addresses randomly assigned to them by DHCP. The switch continues to use the old IP address unless you manually change it; however the Device Manager prompts you if it does detect this situation. UNIX workstations have a built-in syslog server. You must have root access (or run the Cisco syslog server as setuid to root) to stop the built-in syslog daemon and start the Cisco syslog server.}}

Revision as of 13:54, 15 July 2010

This section introduces the basic concepts, methodology, and general troubleshooting guidelines for problems that may occur when configuring and using the Cisco MDS 9000 Family of multilayer directors and fabric switches.

Overview of the Troubleshooting Process

Systematically eliminate each potential problem (from most likely to least likely) until the symptoms disappear.

To identify the possible problems, you need to use a variety of tools and understand the overall storage environment. For this reason, this guide describes a number of general troubleshooting tools in Appendix B, "Troubleshooting Tools and Methodology," including those that are specific to the Cisco MDS 9000 Family. This chapter also provides a plan for investigating storage issues. See other chapters in this book for detailed explanations of specific issues.

Best Practices

Best practices are the recommended steps you should take to ensure the proper operation of your fabric. We recommend the following general best practices for most SAN fabrics:

Refer to the release notes for your Cisco SAN-OS release for the latest features, limitations, and caveats.

Enable system message logging. See the "System Messages" section.

Troubleshoot any new configuration changes after implementing the change.

Use Fabric Manager and Device Manager to proactively manage your fabric and detect possible problems before they become critical.

Troubleshooting Basics

This section provides a series of questions that may be useful when troubleshooting a problem with a Cisco MDS 9000 Family switch or connected devices. Use the answers to these questions to plan a course of action and to determine the scope of the problem. For example, if a host can only access some, but not all, of the logical unit numbers (LUNs) on an existing subsystem, then fabric-specific issues (such as FSPF, ISLs, or FCNS) do not need to be investigated. The fabric components can therefore be eliminated from possible causes of the problem.

General Steps

The two most common symptoms of problems in a storage network are:

A host cannot access its allocated storage

An application does not respond after attempting to access the allocated storage

By answering the questions in the following subsections, you can determine the paths you need to follow and the components that you should investigate further. These questions are independent of host, switch, or subsystem vendor.

Answer the following questions to determine the status of your installation:

Is this a newly installed system or an existing installation? (It could be a new SAN, host, or subsystem, or new LUNs exported to an existing host.)

Has the host ever been able to see its storage?

Does the host recognize any LUNs in the subsystem?

Are you trying to solve an existing application problem (too slow, too high latency, excessively long response time) or did the problem show up recently?

What changed in the configuration or in the overall infrastructure immediately before the applications started to have problems?

To discover a SAN problem, use the following general SAN troubleshooting steps:

Gather information on problems in your fabric. See the "Gathering Information Using Common Fabric Manager Tools and CLI Commands" section.

Verify physical connectivity between your switches and end devices. See the "Verifying Basic Connectivity" section.

Verify registration to your fabric for all SAN elements. See the "Verifying SAN Element Registration" section.

Verify the configuration for your end devices (storage subsystems and servers).

Gathering Information Using Common Fabric Manager Tools and CLI Commands

This section highlights the Fabric Manager tools and CLI commands that are commonly used to troubleshoot problems within your fabric. These tools and commands are a subset of what you may use to troubleshoot your specific problem.

Each section in this guide may include additional tools and commands specific to the symptoms and possible problems covered in that chapter.

Common Fabric Manager Tools
Use the following navigation paths in Fabric Manager or Device Manager to access common troubleshooting information:

Common CLI Commands
Issue the following commands and examine the outputs:

show module

show version

show running-config

show logging log

show interfaces brief

show fcns

show flogi

show hardware internal errors

show zoneset active

show accounting log

Note:

Use the show running interface CLI command to view the interface configuration in Cisco SAN-OS Release 3.0(1) or later. The interface configuration as seen in the show running-config CLI command is no longer consolidated.

Note:

To issue commands with the internal keyword, you must have an account that is a member of the network-admin group.

Verifying Basic Connectivity

Answer the following questions to verify basic connectivity between your end devices:

Are you using the correct fiber (SM or MM)?

Did you check for a broken fiber?

Is the Fibre Channel port LED on the connected module green, and do the LEDs on any host bus adapter (HBA)/storage subsystem ports indicate normal functionality?

Is there a LUN masking policy applied on the storage subsystem? If yes, is the server allowed to see the LUNs exported by the storage array?

Is there a LUN masking policy configured on the host? Did you enable the server to see all the LUNs it can access?

If LUN masking software is used, is the host's pWWN listed in the LUN masking database?

Is the subsystem configured for an N port?

Examine the FLOGI database on the two switches that are directly connected to the host HBA and subsystem ports. Also, verify that both ports (attached to MDS-A and MDS-B) are members of the same VSAN. If both devices are listed in the FCNS database then ISLs are not an issue.

In Fabric Manager, choose Tools > Ping or Tools > Traceroute (or use the fcping or fctrace CLI commands) to verify connectivity. See the "FC Ping and FC Traceroute".

Verifying SAN Element Registration

Answer the following questions to verify that your end devices are registered to the fabric:

Are the HBAs and subsystem ports successfully registered with the fabric name server?

In Device Manager, choose FC > Name Server.

In the CLI, use the show fcns commands.

Does the correct pWWN for the HBAs and the storage subsystem ports show up on the correct port in the FLOGI database?

Green box: A successful fabric login has occurred; the connection is active.

Red X: A small form-factor pluggable (SFP) transceiver is present but there is no connection. This could indicate a disconnected or faulty cable, or no active device connection.

Red box: An SFP is present but fabric login (FLOGI) has failed. Typically there is a mismatch in port or fabric parameters with the neighboring device. For example, a port parameter mismatch would occur if a node device were connected to a port configured as an E port. An example of a fabric parameter mismatch would be differing timeout values.

Yellow box: In Device Manager, a port has been selected.

Gray box: The port is administratively disabled.

Black box: An SFP is not present.

Device Manager: Summary View
In Device Manager, selecting the Summary View expands the information available for port monitoring. (See Figure 1-2.) The display includes the following:

VSAN assignment

For N ports, the port World Wide Name (pWWN) and Fibre Channel ID (FC ID) of the connected device

For ISLs, the IP address of the connected switch

Speed

Frames transmitted and received

Percentage utilization for the CPU, dynamic memory, and Flash memory

Device Manager: Port Selection
To drill down for additional port information, use the Device View or Summary View. Select and double-click any port. The initial display shows administrative settings for Mode, Speed, and Status, plus current operational status, failure cause, and date of the last configuration change.

Device Manager: Port Monitoring
To display additional details about port traffic, use the Device View or Summary View. In Device View, choose one or more ports, right-click and choose Monitoring from the pop-up menu. In Summary View, choose one or more interfaces, and click the Monitor tool. The initial display shows traffic statistics for the selected interval, including bytes and frames transmitted and received.

Frame Errors—View frame error statistics, including the number of frames with invalid CRC, Class 3 frames that were discarded upon reception, FBSY returns for selected situations, and FRJT returns resulting from frame rejection by fabric.

Class 2 Traffic—View the amount of Class 2 traffic for the selected interval.

Device Manager: Oversubscription Information
Device Manager provides oversubscription information for supported switching modules and line cards. Use the Device View to view an individual module and then right-click to select from the following tasks:

Primary Troubleshooting Flowchart

The flowchart in the following figure shows the overall troubleshooting process. Begin any troubleshooting investigation by checking one of the following four areas:

Physical port issues

Physical switch issues

Fx port issues

Fabric services

System Messages

The system software sends these syslog (system) messages to the console (and, optionally, to a logging server on another system) during operation. Not all messages indicate a problem with your system. Some messages are purely informational, while others might help diagnose problems with links, internal hardware, or the system software.

System Message Text

Message-text is a text string that describes the condition. This portion of the message might contain detailed information about the event, including terminal port numbers, network addresses, or addresses that correspond to locations in the system memory address space. Because the information in these variable fields changes from message to message, it is represented here by short strings enclosed in square brackets ([ ]). A decimal number, for example, is represented as [dec].

PORT-3-IF_UNSUPPORTED_TRANSCEIVER: Transceiver for interface [chars] is not supported.

Use this string to find the matching system message in the Cisco MDS 9000 Family System Messages Reference.

Each system message is followed by an explanation and recommended action. The action may be as simple as "No action required." It may involve a fix or a recommendation to contact technical support as shown in the following example:

Error Message PORT-3-IF_UNSUPPORTED_TRANSCEIVER: Transceiver for interface [chars] is not supported.

Explanation Transceiver (SFP) is not from an authorized vendor.

Recommended Action Enter the show interface transceiver CLI command or similar Fabric Manager/Device Manager command to determine the transceiver being used. Please contact your customer support representative for a list of authorized transceiver vendors.

Syslog Server Implementation

The syslog facility allows the Cisco MDS 9000 Family platform to send a copy of the message log to a host for more permanent storage. This can be useful if the logs need to be examined over a long period of time or when the Cisco MDS switch is not accessible.

This example will demonstrate how to configure a Cisco MDS switch to utilize the syslog facility on a Solaris platform. Although a Solaris host is being used, syslog configuration on all UNIX and Linux systems is very similar.

Syslog uses the concept of a facility to determine how it should be handled on the syslog server (the Solaris system in this example), and the message severity. Therefore, different message severities can be handled differently by the syslog server. They could be logged to different files or e-mailed to a particular user. Specifying a severity determines that all messages of that level and greater severity (lower number) will be acted upon.

Note:

The Cisco MDS messages should be logged to a different file from the standard syslog file so that they cannot be confused with other non-Cisco syslog messages. The logfile should not be located on the / file system, to prevent log messages from filling up the / file system.

If CFS is enabled in Fabric Manager for the syslog feature, click CFS to commit these changes to propagate the configuration through the fabric.

Device Manager allows you to view event logs on your local PC as well as those on the switch. For a permanent record of all events that occur on the switch, you should store these messages off the switch. To do this the Cisco MDS switch must be configured to send syslog messages to your local PC and a syslog server must be running on that PC to receive those messages. These messages can be categorized into four classes:

Hardware—Line card or power supply problems

Link incidents—FICON port condition changes

Accounting—User change events

Events—All other events

Note:

You should avoid using PCs that have IP addresses randomly assigned to them by DHCP. The switch continues to use the old IP address unless you manually change it; however the Device Manager prompts you if it does detect this situation. UNIX workstations have a built-in syslog server. You must have root access (or run the Cisco syslog server as setuid to root) to stop the built-in syslog daemon and start the Cisco syslog server.