MDS Troubleshooting
MDS Troubleshooting
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Copyright © 2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ
Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo,
Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ
Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm,
SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.
(0303R)
CONTENTS
Preface ix
Document Organization ix
Document Conventions x
Related Documentation x
Introduction 1-1
Basics 1-2
Basic Connectivity 1-2
Fibre Channel End-to-End Connectivity 1-2
Fabric Issues 1-3
Contacting Customer Support 1-3
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
CHA PTER 3 Troubleshooting Switch Level Issues and Interswitch Connectivity 3-1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Troubleshooting Zones – Case of end devices belonging to the default zone 3-19
Troubleshooting Zones – Case of end devices belonging to a specific zone 3-19
Verify active zoneset configuration 3-19
Verify active zoneset membership 3-20
Other useful commands 3-21
Using the GUI to Troubleshoot Zoning Configuration Issues 3-22
Troubleshooting VSANs 3-23
Using the GUI to Troubleshoot VSAN Membership Problems 3-24
Troubleshooting Hardware Problems 3-25
Overview 5-1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Configuring an OUI 60
Can I Set the Map Layout So It Stays After I Restart Fabric Manager? 61
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Are There Any Restrictions When Using Fabric Manager Across FCIP? 62
INDEX
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Preface
This document is intended to provide guidance for troubleshooting issues that may appear when
deploying a storage area network (SAN) using the Cisco MDS 9000 Family of switches. This document
will help you investigate the configuration of the different systems included in the SAN environment,
such as hubs, hosts, and storage arrays and Cisco MDS 9000 switches. It also covers basic storage
commands, switch configurations, and common storage parameters. It introduces tools and
methodologies to recognize a problem, determine its cause, and find possible solutions.
Document Organization
This document is organized into the following chapters:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Document Conventions
Command descriptions use these conventions:
screen font Terminal sessions and information the switch displays are in screen font.
boldface screen font Information you must enter is in boldface screen font.
italic screen font Arguments for which you supply values are in italic screen font.
< > Nonprinting characters, such as passwords are in angle brackets.
[ ] Default responses to system prompts are in square brackets.
!, # An exclamation point (!) or a pound sign (#) at the beginning of a line of code
indicates a comment line.
Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Related Documentation
For Fabric Manager and Device Manager field descriptions, refer to the Cisco MDS 9000 Family Fabric
Manager Online Help. For additional information, refer to the following documents:
• Regulatory Compliance and Safety Information for the Cisco MDS 9000 Family
• Cisco MDS 9100 Series Hardware Installation Guide
• Cisco MDS 9200 Series Hardware Installation Guide
• Cisco MDS 9500 Series Hardware Installation Guide
• Cisco MDS 9000 Family Configuration Guide
• Cisco MDS 9000 Family Command Reference
• Cisco MDS 9000 Family System Messages Guide
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
For information on VERITAS Storage Foundation™ for Networks 1.0, Cisco software, refer to the
following Veritas documents available at http://support.veritas.com/:
• VERITAS Storage Foundation for Networks Overview
• VERITAS Storage Foundation for Networks Installation and Configuration Guide
• VERITAS Storage Foundation for Networks Obtaining and Installing Licenses
• VERITAS Storage Foundation for Networks GUI Administrator's Guide
• VERITAS Storage Foundation for Networks CLI Administrator's Guide
• VERITAS Storage Foundation for Networks README
For information on IBM TotalStorage SAN Volume Controller Storage Software for Cisco MDS 9000,
refer to the following IBM documents available at http://www.ibm.com/storage/support/2062-2300
• IBM TotalStorage SAN Volume Controller Storage Software for Cisco MDS 9000 Getting Started
• IBM TotalStorage SAN Volume Controller Storage Software for Cisco MDS 9000 Configuration
Guide
• IBM TotalStorage SAN Volume Controller Storage Software for Cisco MDS 9000 Command-Line
Interface User's Guide
• IBM TotalStorage Enterprise Storage Server
• IBM TotalStorage SAN Volume Controller
• IBM TotalStorage SAN Volume Controller for Cisco MDS 9000
• Subsystem Device Driver User's 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:
http://www.cisco.com
International Cisco websites 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 regularly
and may be more current than printed documentation. The CD-ROM package is available as a single unit
or through an annual or quarterly subscription.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Registered Cisco.com users can order a single Documentation CD-ROM (product number
DOC-CONDOCCD=) through the Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/ordering_place_order_ordering_tool_launch.html
All users can order monthly or quarterly subscriptions 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
• 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 [email protected].
You can submit comments by using the response card (if present) 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-9883
We appreciate your comments.
Cisco provides Cisco.com, which includes the Cisco Technical Support website, as a starting point for
all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips,
and sample configurations from the Cisco Technical Support Website. Cisco.com registered users have
complete access to the technical support resources on the Cisco Technical Support Website, including
technical support tools and utilities.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
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:
http://tools.cisco.com/RPF/register/register.do
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco
Technical Support Website, you can open a case online at this URL:
http://www.cisco.com/techsupport/caseopen
If you have Internet access, we recommend that you open P3 and P4 cases online so that you can fully
describe the situation and attach any necessary files.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
• Training—Cisco offers world-class networking training. Current offerings in network training are
listed at this URL:
http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html
C H A P T E R 1
Troubleshooting Overview
This chapter introduces the basic concepts, methodology, and tools to use for troubleshooting problems
that may occur when configuring and using a Cisco MDS 9000 Family switch. The two most common
symptoms of problems occurring in a storage network are:
• A host not accessing its allocated storage
• An application not responding after attempting to access the allocated storage
To identify the possible problems, you need to use a variety of tools and understand the overall storage
environment. For this reason, this chapter describes a number of general troubleshooting tools and
procedures in addition to those that are specific to the Cisco MDS 9000 family. This chapter also
provides a plan of attack for investigating storage issues. Refer to the other chapters in this book for
detailed explanations of specific issues.
This chapter includes the following sections:
• Introduction, page 1-1
• Contacting Customer Support, page 1-3
• Using Host Diagnostic Tools, page 1-3
• Using Cisco MDS 9000 Family Tools, page 1-4
• Using Cisco Network Management Products, page 1-18
• Using Other Troubleshooting Products, page 1-22
Introduction
Some basic questions should be answered before you go into too much detail about specific problems
and solutions. A process of elimination can determine which network components have been subject to
change and therefore may be the cause of your problems. The main steps you should follow to identify
a problem in a SAN environment include:
1. Verify physical connectivity and registration to the fabric
2. Verify storage subsystem and server configuration
3. Verify end-to-end connectivity and fabric configuration
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 see some of the
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
LUNs, (but not all of them) on an existing subsystem, then fabric-specific issues (FSPF, ISLs, FCNS) do
not need to be investigated, as they are currently working correctly. The fabric components can therefore
be eliminated from the problem.
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.
Basics
• 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?
Basic Connectivity
• Are you using the correct fiber (SM or MM)?
• Did you check for a broken fiber?
• Is the LED on the connected module Fibre Channel port green, and do the LEDs on any
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 any 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 NPort?
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 port on 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.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
You can use the HBA configuration utilities or the host system logs to determine if the subsystem
PWWN or FCID is listed as a device. This can validate that FSPF is working correctly.
Fabric Issues
• Are both the host bus adapter (HBA) and the subsystem port successfully registered with the fabric
name server?
• Does the correct PWWN for the Server HBA and the storage subsystem port show up on the correct
port in the FLOGI database? In other words, is the device plugged into the correct port?
• Does any single zone contain both devices? The zone members can be WWNs, FCIDs.
• Is the zone correctly configured and part of the active configuration or zoneset within the same
VSAN?
• Do the ISLs show any VSAN isolation?
• Do the host and storage belong to the same VSAN?
• Are any parameters, such as FSPF, Static Domain Assignment, VSAN or Zoning, mismatched in the
configuration of the different switches in the fabric?
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
http://sourceforge.net/projects/iometer/
Iometer is not the only I/O generator you can use to simulate traffic through the SAN fabric. Other
popular I/O generators and benchmark tools used for SAN testing include Iozone and Postmark. Iozone
is a file system benchmark tool that generates and measures a variety of file operations. It has been
ported to many systems and is useful for performing a broad range of file system tests and analysis.
Postmark was designed to create a large pool of continually changing files, which simulates the
transaction rates of a large Internet mail server.
PostMark generates an initial pool of random text files in a configurable range of sizes. Creation of the
pool produces statistics on continuous small file creation performance. Once the pool is created,
PostMark generates a specified number of transactions, each of which consists of a pair of smaller
transactions:
• Create file or Delete file
• Read file or Append file
Benchmark is available from Network Appliance, Inc. at the following URL:
http://www.netapp.com/tech_library/3022.html
Benchmarking tools offer a variety of capabilities and you should select the one that provides the best
I/O characteristics of your application environment.
Utilities provided by the Sun Solaris operating system let you determine if the remote storage has been
recognized and exported to you in form of a raw device or mounted file system, and to issue some basic
queries and tests to the storage. You can measure performance and generate loads using the iostat utility,
the perfmeter GUI utility, the dd utility, or a third-party utility like Extreme SCSI.
Every UNIX version provides similar utilities, but this guide only provides examples for Solaris. Refer
to the documentation for your specific operating system for details.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Command-Line-Interface (CLI)
The Cisco MDS 9000 Family CLI lets you configure and monitor a Cisco MDS 9000 Family switch
using a local console or remotely using a Telnet or SSH session. The CLI provides a command structure
similar to Cisco IOS® software, with context-sensitive help, show commands, multi-user support, and
roles-based access control.
CLI Debug
The Cisco MDS 9000 Family of switches includes an extensive debugging feature set for actively
troubleshooting a storage network. Using the CLI, you can enable debugging modes for each switch
feature and view a real-time updated activity log of the control protocol exchanges. Each log entry is
time-stamped and listed in chronological order. Access to the debug feature can be limited through the
CLI roles mechanism and can be partitioned on a per-role basis. While debug commands show realtime
information, the show commands can be used to list historical information as well as realtime.
Note You can log debug messages to a special log file, which is more secure and easier to process than sending
the debug output to the console.
By using the '?' option, you can see the options that are available for any switch feature, such as FSPF.
A log entry is created for each entered command in addition to the actual debug output. The debug output
shows a time-stamped account of activity occurring between the local switch and other adjacent
switches.
You can use the debug facility to keep track of events, internal messages and protocol errors. However,
you should be careful with using the debug utility in a production environment, because some options
may prevent access to the switch by generating too many messages to the console or if very
CPU-intensive may seriously affect switch performance.
Note It is a good idea to open a second Telnet or SSH session before entering any debug commands. That way,
if the debug output comes too fast to stop it in the output window, you can use the second session to enter
the undebug all command to stop the debug message output.
The following is an example of the output from the debug flogi event command
switch# debug flogi event interface fc1/1
Dec 10 23:40:26 flogi: current state [FLOGI_ST_FLOGI_RECEIVED]
Dec 10 23:40:26 flogi: current event [FLOGI_EV_VALID_FLOGI]
Dec 10 23:40:26 flogi: next state [FLOGI_ST_GET_FCID]
Dec 10 23:40:26 flogi: fu_fsm_execute: ([1]21:00:00:e0:8b:08:96:22)
Dec 10 23:40:26 flogi: current state [FLOGI_ST_GET_FCID]
Dec 10 23:40:26 flogi: current event [FLOGI_EV_VALID_FCID]
Dec 10 23:40:26 flogi: next state [FLOGI_ST_PERFORM_CONFIG]
Dec 10 23:40:26 flogi: fu_fsm_execute: ([1]21:00:00:e0:8b:08:96:22)
Dec 10 23:40:26 flogi: current state [FLOGI_ST_PERFORM_CONFIG]
Dec 10 23:40:26 flogi: current event [FLOGI_EV_CONFIG_DONE_PENDING]
Dec 10 23:40:26 flogi: next state [FLOGI_ST_PERFORM_CONFIG]
Dec 10 23:40:26 flogi: fu_fsm_execute: ([1]21:00:00:e0:8b:08:96:22)
Dec 10 23:40:26 flogi: current state [FLOGI_ST_PERFORM_CONFIG]
Dec 10 23:40:26 flogi: current event [FLOGI_EV_RIB_RESPOSE]
Dec 10 23:40:26 flogi: next state [FLOGI_ST_PERFORM_CONFIG]
Dec 10 23:40:26 flogi: fu_fsm_execute: ([1]21:00:00:e0:8b:08:96:22)
Dec 10 23:40:26 flogi: current state [FLOGI_ST_PERFORM_CONFIG]
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note FC Ping and FC traceroute are used to troubleshoot problems with connectivity and path choices. They
are not designed for use in identifying or resolving performance issues.
Ping and Traceroute are two of the most useful tools for troubleshooting TCP/IP networking problems.
The Ping utility generates a series of echo packets to a destination across a TCP/IP internetwork. When
the echo packets arrive at the destination, they are re-routed and sent back to the source. Using Ping, you
can verify connectivity and latency to a particular destination across an IP routed network. Traceroute
operates in a similar fashion, but can also determine the specific path that a frame takes to its destination
on a hop-by-hop basis. These tools have been migrated to Fibre Channel for use with the Cisco MDS
9000 Family switches and are called FC Ping and FC Traceroute. You can use FC Ping and FC
Traceroute from the CLI or from the Cisco Fabric Manager.
FC Ping allows you to ping a Fibre Channel N_Port or end device. By specifying the FC_ID or Fibre
Channel address, you can send a series of frames to a target N_Port. Once these frames reach the target
device’s N_Port, they are looped back to the source and a time-stamp is taken. FC Ping helps you to
verify the connectivity and latency to an end N_Port. FC Ping uses the PRLI Extended Link Service, and
verifies the presence of a FC entity in case of positive or negative answers.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
FC Traceroute is slightly different than the IP equivalent because both the outbound and return paths are
recorded as these may differ in a switched Fibre Channel network. The FC Traceroute command
identifies the path taken on a hop-by-hop basis and includes a timestamp at each hop in both directions.
FC Ping and FC Traceroute are useful tools to check for network connectivity problems or verify the
path taken toward a specific destination. You can use FC Traceroute to test the connectivity of TE ports
along the path between the generating switch and the switch closest to the destination.
Note The values rendered by the FCtrace process do not reflect the actual latency across the switches. The
actual trace value interpretation is shown in the example below.
VSAN 600
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPEFEATURE
--------------------------------------------------------------------------
0xeb01e8 NL 210000203767f7a2 (Seagate) scsi-fcptarget
0xec00e4 NL 210000203767f48a (Seagate) scsi-fcp
0xec00e8 NL 210000203767f507 (Seagate) scsi-fcp
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note For detailed information about using Cisco Fabric Manager, refer to the Cisco MDS 9000 Family Fabric
Manager User Guide.
Note When you click on a zone or VSAN in Fabric Manager, the members of the zone or VSAN are
highlighted on the Fabric Manager Map pane.
Device Manager provides a graphic display of a specific switch and shows the status of each port on the
switch. From Device Manager, you can drill down to get detailed statistics about a specific switch or
port.
Figure 1-1 shows the Device Manager Summary View window.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The Summary View window lets you analyze switch performance issues, diagnose problems, and change
parameters to resolve problems or inconsistencies. This view shows aggregated statistics for the active
Supervisor Module and all switch ports. Information is presented in tabular or graphical formats, with
bar, line, area, and pie chart options. You can also use the Summary View to capture the current state of
information for export to a file or output to a printer.
The Switch Health Analysis window displays any problems affecting the selected switches.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
You use a policy file to define the rules to be applied when running the Fabric Checker. When you create
a policy file, the system saves the rules selected for the selected switch.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The Zone Merge Analysis window displays any inconsistencies between the zone configuration of the
two selected switches.
You can use the following options on the Fabric Manager Tools menu to verify connectivity to a selected
object or to open other management tools:
• Traceroute—Verify connectivity between two end devices that are currently selected on the Map
pane.
• Device Manager— Launch Device Manager for the switch selected on the Map pane.
• Command Line Interface—Open a Telnet or SSH session for the switch selected on the Map pane.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note This tool can be effective to find out the number of LUNs exported by a storage subsystem, but it may
be ineffective when LUN Zoning/LUN Security tools are used.
Note During initial configuration of your switch, the system prompts you to define SNMP v1 or V2
community strings and to create a SNMP v3 username and password.
Cisco MDS 9000 Family switches support over 50 different MIBs, which can be divided into the
following six categories:
• IETF Standards-based Entity MIBs (for example, RFC273 ENTITY-MIB) These MIBs are used to
report information on the physical devices themselves in terms of physical attributes etc.
• Cisco-Proprietary Entity MIBs (for example, CISCO-ENTITY-FRU-CONTROL-MIB) These
MIBs are used to report additional physical device information about Cisco-only devices such as
their configuration.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
• IETF IP Transport-oriented MIBs (for example, RFC2013 UDP-MIB) These MIBs are used to
report transport-oriented statistics on such protocols as IP, TCP, and UDP. These transports are used
in the management of the Cisco MDS 9000 Family through the OOB Ethernet interface on the
Supervisor module.
• Cisco-Proprietary Storage and Storage Network MIBs (for example, NAME-SERVER-MIB) These
MIBs were written by Cisco to help expose information that is discovered within a fabric to
management applications not connected to the fabric itself. In addition to exposing configuration
details for features like zoning and Virtual SANs (VSANs) via MIBs, discovered information from
sources like the FC-GS-3 Name Server can be pulled via a MIB. Additionally, MIBs are provided
to configure/enable features within the Cisco MDS 9000 Family. There are over 20 new MIBs
provided by Cisco for this information and configuration capability.
• IETF IP Storage Working Group MIBs (for example, ISCSI-MIB) While many of these MIBs are
still work-in-progress, Cisco is helping to draft such MIBs for protocols such as iSCSI and Fibre
Channel-over-IP (FCIP) to be standardized within the IETF.
• Miscellaneous MIBs (for example, SNMP-FRAMEWORK-MIB) There are several other MIBs
provided in the Cisco MDS 9000 Family switches for tasks such as defining the SNMP framework
or creating SNMP partitioned views.
You can use SNMPv3 to assign different SNMP capabilities to specific roles.
Cisco MDS 9000 Family switches also support Remote Monitoring (RMON) for Fibre Channel. RMON
provides a standard method to monitor the basic operations of network protocols providing connectivity
between SNMP management stations and monitoring agents. RMON also provides a powerful alarm and
event mechanism for setting thresholds and sending notifications based on changes in network behavior.
The RMON groups that have been adapted for use with Fibre Channel include the AlarmGroup and
EventGroup. The AlarmGroup provides services to set alarms. Alarms can be set on one or multiple
parameters within a device. For example, you can set an RMON alarm for a specific level of CPU
utilization or crossbar utilization on a switch. The EventGroup lets you configure events that are actions
to be taken based on an alarm condition. The types of events that are supported include logging, SNMP
traps, and log-and-trap.
Note To configure events within an RMON group, use the Events > Threshold Manager option from Device
Manager.
Using RADIUS
RADIUS is fully supported for the Cisco MDS 9000 Family switches through the Fabric Manager and
the CLI. RADIUS is a protocol used for the exchange of attributes or credentials between a head-end
RADIUS server and a client device. These attributes relate to three classes of services:
• Authentication
• Authorization
• Accounting
Authentication refers to the authentication of users for access to a specific device. You can use RADIUS
to manage user accounts for access to Cisco MDS 9000 Family switches. When you try to log into a
switch, the switch validates you with information from a central RADIUS server.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Authorization refers to the scope of access that you have once you have been authenticated. With Cisco
MDS 9000 Family switches, assigned roles for users can be stored in a RADIUS server along with a list
of actual devices that the user should have access to. Once the user has been authenticated, then switch
can then refer to the RADIUS server to determine the extent of access the user will have within the
switch network.
Accounting refers to the log information that is kept for each management session in a switch. This
information may be used to generate reports for troubleshooting purposes and user accountability.
Accounting can be implemented locally or remotely (using RADIUS).
The following is an example of an accounting log entries.
switch# show accounting log
Sun Dec 15 04:02:27 2002:start:/dev/pts/0_1039924947:admin
Sun Dec 15 04:02:28 2002:stop:/dev/pts/0_1039924947:admin:vsh exited normally
Sun Dec 15 04:02:33 2002:start:/dev/pts/0_1039924953:admin
Sun Dec 15 04:02:34 2002:stop:/dev/pts/0_1039924953:admin:vsh exited normally
Sun Dec 15 05:02:08 2002:start:snmp_1039928528_172.22.95.167:public
Sun Dec 15 05:02:08 2002:update:snmp_1039928528_172.22.95.167:public:Switchname
set to Switch
Note The accounting log only shows the beginning and ending (start and stop) for each session.
Using Syslog
Syslog lets you store a chronological log of system messages locally or sent to a central Syslog server.
Syslog messages can also be sent to the console for immediate use. These messages can vary in detail
depending on the configuration that you choose. Syslog messages are categorized into 7 severity levels
from debug to critical events. You can limit the severity levels that are reported for specific services
within the switch. For example, you may wish only to report debug events for the FSPF service but
record all severity level events for the Zoning service.
A unique feature within the Cisco MDS 9000 Family switches is the ability to send RADIUS accounting
records to the Syslog service. The advantage of this feature is that you can consolidate both types of
messages for easier correlation. For example, when you log into a switch and change an FSPF parameter,
Syslog and RADIUS provide complimentary information that will help you formulate a complete picture
of the event.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
To use a protocol analyzer, you must insert the analyzer in-line with the device under analysis, which
disrupts input and output (I/O) to and from the device. This problem is worse when the point of analysis
is on an Inter-Switch Link (ISL) link between two switches. In this case, the disruption may be
significant depending on what devices are downstream from the severed ISL link.
In Ethernet networks, this problem can be solved using the SPAN utility, which is provided with the
Cisco Catalyst Family of Ethernet switches. SPAN has also been implemented with the Cisco MDS 9000
Family of switches for use in Fibre Channel networks. SPAN lets you take a copy of all traffic and direct
it to another port within the switch. The process is non-disruptive to any connected devices and is
facilitated in hardware, which prevents any unnecessary CPU load. Using Fibre Channel SPAN, you can
connect a Fibre Channel analyzer, such as a Finisar analyzer, to an unused port on the switch and then
SPAN a copy of the traffic from a port under analysis to the analyzer in a non-disruptive fashion.
SPAN allows you to create up to 16 independent SPAN sessions within the switch. Each session can have
up to four unique sources and one destination port. In addition, you can apply a filter to capture only the
traffic received or the traffic transmitted. With Fibre Channel SPAN, you can even capture traffic from
a particular Virtual SAN (VSAN).
To start the SPAN utility use the CLI command span session session_num, where session_num
identifies a specific SPAN session. When you enter this command, the system displays a submenu, which
lets you configure the destination interface and the source VSAN or interfaces.
switch2# config terminal
switch2(config)# span session 1
<<Create a span session>>
switch2(config-span)# end
switch2# show span session 1
Session 1 (active)
Destination is fc1/1
No session filters configured
Ingress (rx) sources are
fc1/8,
Egress (tx) sources are
fc1/8,
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note The Cisco Port Analyzer Adapter does not support half-duplex mode and for this reason, it will not work
when connected to a hub.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
When used in conjunction with the open source protocol analyzer, Ethereal (http//www.ethereal.com),
the Cisco Port Analyzer Adapter provides a cost-effective and powerful troubleshooting tool. It allows
any PC with a Ethernet card to provide the functionality of a flexible Fibre Channel analyzer. For more
information on using the Cisco Port Analyzer Adapter see the Cisco MDS 9000 Family Port Analyzer
Adapter Installation and Configuration Guide.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The Cisco Fabric Analyzer captures and analyzes control traffic coming to the Supervisor Card. This tool
is much more effective than the debug facility for packet trace and traffic analysis, because it is not very
CPU intensive and it provides a graphic interface for easy analysis and decoding of the captured traffic.
switch# config terminal
switch(config)# fcanalyzer local brief
Capturing on eth2
0.000000 ff.ff.fd -> ff.ff.fd SW_ILS 1 0x59b7 0xffff 0x7 -> 0xf HLO
0.000089 ff.ff.fd -> ff.ff.fd FC 1 0x59b7 0x59c9 0xff -> 0x0 Link Ctl, ACK1
1.991615 ff.ff.fd -> ff.ff.fd SW_ILS 1 0x59ca 0xffff 0xff -> 0x0 HLO
1.992024 ff.ff.fd -> ff.ff.fd FC 1 0x59ca 0x59b8 0x7 -> 0xf Link Ctl, ACK1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
However, the Cisco Fabric Analyzer is not the right tool for troubleshooting end-to-end problems
because it cannot access any traffic between the server and storage subsystems. That traffic is switched
locally on the linecards, and does not reach the Supervisor card. In order to debug issues related to the
communication between server and storage subsystems, you need to use Fibre Channel SPAN with an
external protocol analyzer.
There are two ways you can start the Cisco Fabric Analyzer from the CLI.
• fcanalyzer local—Launches the text-based version on the analyzer directly on the console screen
or on a file local to the system.
• fcanalyzer remote ip address—Activates the remote capture agent on the switch, where ip address
is the address of the management station running Ethereal.
CiscoWorks RME
CiscoWorks Resource Manager Essentials (RME) is a set of CiscoWorks applications that provide
comprehensive resource management capabilities. With the introduction of the Cisco MDS 9000 Family
of switches, CiscoWorks RME has been extended to provide resource management services to a Cisco
MDS 9000 Family storage network.
CiscoWorks RME comprises a set of resource management services. The following list outlines the
services provided by CiscoWorks RME for the Cisco MDS 9000 Family of switches.
• Inventory Manager—Provides a facility to gather and audit a detailed hardware and software
inventory of all Cisco MDS 9000 Family devices deployed in the storage network. A reporting
facility is included to generate inventory reports
• Configuration Manager—Maintains an active repository of device configuration files for devices
that are managed. It provides facility to upload and download configuration files to/from devices and
a facility to log a record in the Change Audit log database when a new version of the configuration
file is archived. Standard reports can be generated for configuration management inventory and
activity.
• Configuration Editor—Provides a powerful web-based editor that allows multiple configuration
files to be checked out of the configuration archive, be updated or changed, and then either saved
locally or downloaded to the device.
• Net Show—Provides a simplified web-based show command interface, allowing show commands to
be run against multiple switches or routers to enhance and simplify network troubleshooting.
• Software Image Manager—Simplifies version management and routine deployment of software
updates to Cisco devices through wizard-assisted planning, scheduling, downloading, and
monitoring of software updates
• Syslog Analyzer—Filters Syslog messages logged by Cisco devices and displays explanations of
probable causes and recommended actions. This tool also helps facilitate manual parsing of Syslog
files for reporting purposes.
CiscoWorks RME provides a system that can manage hardware, software, and configuration inventory
across multiple infrastructures including storage networks, LANs, MANs, and WANs.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
C H A P T E R 2
Troubleshooting Switch System Issues
This chapter describes how to identify and resolve problems that might occur when accessing or starting
up a single Cisco MDS 9000 Family switch. It includes the following sections:
• Recovering the Administrator Password, page 2-1
• Troubleshooting System Restarts, page 2-1
• Troubleshooting a Failed Supervisor, page 2-7
Overview
There are three different types of system restarts:
• Recoverable—A process restarts and service is not affected.
• Unrecoverable—A process is not restartable or it has restarted more than the max restart times
within a fixed period of time (seconds) and will not be restarted again.
• System Hung/Crashed—No communications of any kind is possible with box.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Most system restarts generate a Call Home event, but the condition causing a restart may become so
severe that a Call Home event is not generated. Be sure that you configure the Call Home feature
properly, follow up on any initial messages regarding system restarts, and fix the problem before it
becomes so severe. For information about configuring Call Home, refer to the Cisco MDS 9000 Family
Configuration Guide or the Cisco MDS 9000 Family Fabric Manager User Guide.
Step 1 Enter the following command to check the Syslog file to see which process restarted and why it restarted.
switch# sh log logfile | include error
For information about the meaning of each message, refer to the Cisco MDS 9000 Family System
Messages Guide
The system output looks like the following:
Sep 10 23:31:31 dot-6 % LOG_SYSMGR-3-SERVICE_TERMINATED: Service "sensor" (PID 704) has
finished with error code SYSMGR_EXITCODE_SY.
switch# show logging logfile | include fail
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 0.0.0.0, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.0.0.1, in_classd=0 flags=0 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.1.1.1, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 172.22.93.88, in_classd=0 flags=1 fails: Address already in use
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/13 is down (Link failure
or not-connected)
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/14 is down (Link failure
or not-connected)
Jan 28 00:55:12 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
Jan 28 00:58:06 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 00:58:44 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 03:26:38 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 29 19:01:34 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
switch#
Step 2 Enter the following command to identify the processes that are running and the status of each process.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following codes are used in the system output for the State (process state):
• D = uninterruptible sleep (usually IO)
• R = runnable (on run queue)
• S = sleeping
• T = traced or stopped
• Z = defunct ("zombie") process
• NR = not-running
• ER = should be running but currently not-running
Note ER usually is the state a process enters if it has been restarted too many times and has been detected as
faulty by the system and disabled.
The system output looks like the following (the output has been abbreviated to be more concise):
PID State PC Start_cnt TTY Process
----- ----- -------- ----------- ---- -------------
1 S 2ab8e33e 1 - init
2 S 0 1 - keventd
3 S 0 1 - ksoftirqd_CPU0
4 S 0 1 - kswapd
5 S 0 1 - bdflush
6 S 0 1 - kupdated
71 S 0 1 - kjournald
136 S 0 1 - kjournald
140 S 0 1 - kjournald
431 S 2abe333e 1 - httpd
443 S 2abfd33e 1 - xinetd
446 S 2ac1e33e 1 - sysmgr
452 S 2abe91a2 1 - httpd
453 S 2abe91a2 1 - httpd
456 S 2ac73419 1 S0 vsh
469 S 2abe91a2 1 - httpd
470 S 2abe91a2 1 - httpd
Step 3 Enter the following command to show the processes that have had abnormal exits and if there is a
stack-trace or core dump.
switch# show process log
Process PID Normal-exit Stack-trace Core Log-create-time
---------------- ------ ----------- ----------- ------- ---------------
ntp 919 N N N Jan 27 04:08
snsm 972 N Y N Jan 24 20:50
Step 4 Enter the following command to show detailed information about a specific process that has restarted:
switch# show processes log pid 898
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 5 Enter the following command to determine if the restart recently occurred:
switch# sh sys uptime
Start Time: Fri Sep 13 12:38:39 2002
Up Time: 0 days, 1 hours, 16 minutes, 22 seconds
To determine if the restart is repetitive or a one-time occurrence, compare the length of time that the
system has been up with the timestamp of each restart.
Step 6 Enter the following command to view the core files:
switch# show cores
This output shows all the cores presently available for upload from the active supervisor. The column
entitled module-num shows the slot# on which the core was generated. In the example shown above, an
fspf core was generated on the active supervisor module in slot 5. An fcc core was generated on the
standby supervisory module in slot 6. Core dumps generated on the line card in slot 8 include acltcam
and fib.
To copy the FSPF core dump in this example to a TFTP server with the IP address 1.1.1.1, enter the
following command:
switch# copy core://5/1524 tftp::/1.1.1.1/abcd
The following command displays the file named zone_server_log.889 in the log directory.
switch# sh pro log pid 1473
======================================================
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Service: ips
Description: IPS Manager
Virtual Memory:
Register Set:
Step 7 Enter the following command configure the switch to use TFTP to send the core dump to a TFTP server.
switch(config)# sys cores tftp:[//servername][/path]
This command causes the switch to enable the automatic copy of core files to a TFTP server. For
example, the following command sends the core files to the TFTP server with the IP address 10.1.1.1.
switch(config)# system cores tftp://10.1.1.1/cores
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
• The maximum number of times a process can be restarted is part of the HA policy for any process
(this parameter is not configurable). If the process restarts more than the maximum number of times,
the older core files are overwritten.
• The maximum number of core files that can be saved for any process is part of the HA policy for
any process (this parameter is not configurable, and it is set to 3).
Step 8 To determine the cause and resolution for the restart condition, call Cisco TAC and ask them to review
your core dump.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
C H A P T E R 3
Troubleshooting Switch Level Issues and
Interswitch Connectivity
This chapter describes how to identify and resolve problems that affect basic connectivity between
switches, hosts, and storage in the network fabric.
The most common problems a system administrator can face may be categorized by two different
scenarios:
• Switch-to-switch basic interconnectivity problems, which can result in the isolation of a port or
VSAN due to incorrect parameters or settings on an ISL or VSAN
• Fabric to Server/Storage connectivity problems: identified by a Fx port not coming up or caused by
zone or VSAN configuration errors
This section will present some of the most common scenarios, in which either switch-to-switch basic
connectivity problems or fabric to end-devices problems can be found.
These scenario are grouped in three different sections:
• Troubleshooting E Port Connectivity - ISL Isolation, page 3-1
• Troubleshooting TE Port Connectivity - VSAN Isolation, page 3-10
• Troubleshooting Fx Port Connectivity, page 3-13
• Troubleshooting Hardware Problems, page 3-25
•
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Overview
On an E port, only one VSAN can be passed and possibly be isolated. However, in a trunking E port
(TE), multiple VSANs can become isolated while others are passing traffic. The same troubleshooting
approach applies in both cases, except that on a trunking E port the troubleshooting may need to be done
on a per-VSAN basis and/or on multiple VSANs.
Step 1) Verify that each VSAN is able to see the other switches within the same VSAN.
To verify that each switch is able to see the other switches, issue the following command at the exec
prompt. This command is VSAN-specific. If a specific VSAN is omitted from the command, it will list
the output for all VSANs.
switch# show fcdomain domain-list vsan 1
The output of the command lists set of domain IDs and associated WWNs for each switch within a
VSAN. This list provides the WWN of the switches owning each domain ID and the information about
the principality of those switches in the fabric or VSAN they belong to.
Sample output #1 (obtained in a fabric with just 2 switches in VSAN 1)
switch# sh fcdomain domain-list vsan 1
Number of domains: 2
Domain ID WWN
--------- --------------------------------
0x4a(74) 20:01:00:05:30:00:13:9f [Local]
0x4b(75) 20:01:00:05:30:00:13:9e [Principal]
------- --------------------------------------
This is an output of VSAN 1 in which 2 switches are seen. This indicates that the switch where the
command has been issued has built its adjacency on VSAN 1 with the other switch in the same VSAN.
Sample output #2
switch# sh fcdomain domain-list vsan 1
Number of domains: 1
Domain ID WWN
--------- -----------------------
0x4a(74) 20:01:00:05:30:00:13:9f [Local] [Principal]
--------- -----------------------
In this output only one switch is seen. This indicates that the switch where the command has been issued
has not established adjacency with the neighboring switch in VSAN 1.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Troubleshooting steps
The first step in the process is to understand the nature of the problem by checking the status of the
E port. The show interface command can be used to display the port status. This command is very useful
in troubleshooting switch connectivity issues. In case of error, this command provides indication of the
protocol error or configuration mismatch that caused the problem, between parenthesis, immediately
after the port operational status.
Sample output#3
switch# show interface fc4/1
fc4/1 is up
Hardware is Fibre Channel
Port WWN is 20:c1:00:05:30:00:13:9e
Peer port WWN is 21:89:00:05:30:00:18:a2
Admin port mode is auto, trunk mode is on
Port mode is E, FCID is 0x6b0000
Port vsan is 1
Speed is 2 Gbps
Receive B2B Credit is 12
Receive Buffer Size is 2112
Encapsulation is normal
Beacon is turned off
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
109 frames input, 9728 bytes, 0 discards
0 CRC, 0 unknown class
0 too long, 0 too short
108 frames output, 6652 bytes, 0 discards
1 input OLS, 3 LRR, 1 NOS, 2 loop inits
4 output OLS, 3 LRR, 3 NOS, 0 loop inits
When the port operational status shows that the port is up, it means that the E port is up and is currently
passing traffic. The output shown above represents the output of a working E port.
Different types of isolation problems can be recognized by running the show interface command:
• Isolation due to ELP failure and mismatch in the switch or port parameters
• Isolation due to zone merge failure
• Isolation due to port/VSAN mismatch
• Isolation due to domain overlap
• Isolation due to invalid fabric reconfiguration
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
In this example the interface is indicating a link isolation caused by an ELP failure on an E port. The
ELP is a frame sent between two switches to negotiate fabric parameters. If you get this failure, verify
the fabric parameters are the same for both switches.
Since fabric parameters are configured on a per switch basis, however, they are required to be the same
for all switches within a fabric.
If the interface indicates an ELP failure verify the following parameters match using the show fctimer
command:
• ED_TOV Timer
• RA_TOV Timer
• FS_TOV timer
An example of the show fctimer command where all default value are in use, is shown below
switch# show fctimer
F_S_TOV : 5000 milliseconds
D_S_TOV : 15000 milliseconds
E_D_TOV : 2000 milliseconds
R_A_TOV : 10000 milliseconds
Another parameter to check, is the Rcxbuffer size on the interface. This value should match on both the
ends of a ISL. To verify the value of the Rcxbuffer size, use the following command:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
FCOT info -
Min Speed: 1000
Max Speed: 2000
Module Type: 8
Connector Type: 7
Gigabit Eth Compliance Codes: 0
FC Transmitter Type: 3
Vendor Name: PICOLIGHT
Vendor ID: 0:4:133
Vendor Part Num: PL-XPL-00-S23-28
Vendor Revision Level:
Trunk Info -
trunk vsans (allowed active) (1)
In the above examples, the highligthed rxbuffsize is 2112 bytes. This represents the default settings on
a Cisco MDS 9000 switch interface.
A E port will segment with (isolation due to zone merge failure) if the following are true.
• If the active zonesets on the two switches differ from each other in terms of zone membership
(provided there are zones at either side with identical names )
• If the active zoneset on both switches contain a zone with the same name but with different zone
members
To verify the zoning information use the following commands:
switch# show zone vsan 1
switch# show zoneset vsan 1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The import option of the command of will overwrite the local switch’s active zoneset with that of the
remote switch. The export option will overwrite the remote switch’s active zoneset with the local
switch’s active zoneset.
• If the zoning databases between the two switches are overwritten, you will not be able to use the
import option. To work around this, you can manually change the content of the zone database on
either of the switches, and then issue a shut/no shut on the isolated port.
If the isolation is specific to one VSAN and not on a E port, the correct way to issue the cycle up/down,
is to remove the VSAN from the list of allowed VSANs on that trunk port, and re-insert it.
Do not simply issue a shut/no shut sequence of commands on the port, because this would affect all the
VSANs crossing the EISL instead of just the VSAN experiencing the isolation problem.
Using the Zone Merge Analysis tool in Fabric Manager, the compatibility of two active zonesets in two
switches can be checked before actually merging the two zonesets. Refer to the Cisco MDS 9000 Fabric
Manager User Guide for more information.
In the above example, the E port isolated because the interface of the 2 switches belong to different
VSANS. To resolve this issue move the interfaces to the same VSAN.
You can check the VSAN membership with the switch interfaces with the following command.
switch# show vsan membership
vsan 1 interfaces:
fc2/1 fc2/2 fc2/3 fc2/4 fc2/6 fc2/7 fc2/8 fc2/9
fc2/10 fc2/11 fc2/12 fc2/14 fc2/15 fc2/16 fc7/1 fc7/2
fc7/3 fc7/4 fc7/5 fc7/6 fc7/7 fc7/8 fc7/9 fc7/10
fc7/11 fc7/12 fc7/13 fc7/14 fc7/15 fc7/16 fc7/17 fc7/18
fc7/19 fc7/20 fc7/21 fc7/22 fc7/23 fc7/24 fc7/25 fc7/26
fc7/27 fc7/28 fc7/29 fc7/30 fc7/31 fc7/32
vsan 2 interfaces:
fc2/5 fc2/13
The command shows that all the interfaces on the switch belong to VSAN 1, with the exception of
interface 2/5 and 2/13 that are part of VSAN 2.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
To view which domain are currently in your fabric use the following command. This command can be
issued to both fabrics to determine which domain IDs are overlapping.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Number of domains: 2
Domain ID WWN
--------- -----------------------
0x4a(74) 20:01:00:05:30:00:13:9f [Local]
0x4b(75) 20:01:00:05:30:00:13:9e [Principal]
------- -----------------------
There are different ways of resolving this issue. One possible solution is to cause an RCF in the fabric
with a disruptive restart of the domain manager on the switch. The RCF functionality will cause all
switches in both fabrics to empty their domain ID list and select a new principal switch. The overlapping
domain ID would be assigned to which ever switch requests it first from the newly selected principal
switch.
The second switch to request that same domain ID would be assigned a new domain ID. This will only
work if the overlapping domain IDs are not statically defined on the switches. If the domain ID is
statically defined on the switch, then the switch does not accept any other domain ID than the one that
is configured. If its request for the configured domain ID is not granted, it isolates itself from the fabric.
The RCF functionality is disruptive and can cause end nodes to be assigned new domain IDs. By default,
Cisco MDS 9000 Family switches accept disruptive restarts. You can configure the switch in order to
reject incoming RCFs on a per-VSAN and port level basis (enabling the rcf-reject option).
In case the rcf-reject option is on, in order to have the RCF propagated to the switches in the fabric,
must have the RCF reject property disabled. To turn this option off use the following command:
At this point a disruptive restart should be triggered, by using the following command:
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# fcdomain restart disruptive vsan 1
switch(config)#
When you do a disruptive restart on your switch and the switch on the other side does not have disruptive
restart enabled the error on the E port would be the following
switch# show interface fc2/5
fc2/5 is down (isolation due to invalid fabric reconfiguration)
Hardware is Fibre Channel
Port WWN is 20:45:00:05:30:00:18:a2
Admin port mode is auto, trunk mode is on
Port vsan is 1
Receive data field size is 2112
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the overlapping domain IDs are statically assigned, or you want to manually assign the new domain
IDs, it would be necessary to go into the switch with the overlapping domain ID, configure a new domain
ID for that switch, and restart the domain manager process to merge the two fabrics. To configure a
domain ID on the switch use the following command. Domain IDs are assigned on a per-VSAN basis.
switch(config)# fcdomain domain 3 preferred vsan 1
switch(config)# fcdomain domain 3 static vsan 1
switch(config)#
When configuring a domain ID on a switch, there are two options - static and preferred. The static option
tells the switch to request that particular domain in the fabric. If it does get that particular address, it will
isolate itself from the fabric. With the preferred option, the switch requests the domain ID, but if that ID
is not available it will accept another ID. After configuring the domain ID it is necessary to restart the
domain manager to merge the two fabrics.
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# fcdomain restart vsan 1
switch(config)#
If a switch cannot get a statically configured address it would isolate itself from the fabric. When it
isolates itself the show interface output is the following.
switch# show interface fc2/14
fc2/14 is down (isolation due to domain overlap )
Hardware is Fibre Channel, WWN is 20:4e:00:05:30:00:63:9e
vsan is 2
Beacon is turned off
192 frames input, 3986 bytes, 0 discards
0 runts, 0 jabber, 0 too long, 0 too short
0 input errors, 0 CRC, 3 invalid transmission words
0 address id, 0 delimiter
0 EOF abort, 0 fragmented, 0 unknown class
231 frames output, 3709 bytes, 16777216 discards
Received 28 OLS, 19 LRR, 16 NOS, 48 loop inits
Transmitted 62 OLS, 22 LRR, 25 NOS, 30 loop inits
While of the neighbor switch E port the message would be the following
switch2# show interface fc9/4
fc9/4 is down (Isolation due to domain other side eport isolated)
Hardware is Fibre Channel
Port WWN is 22:04:00:05:30:00:13:9e
Admin port mode is auto, trunk mode is off
Port vsan is 1
Receive data field size is 2112
Beacon is turned off
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
To fix the issue, the administrator can either change the static domain ID that is overlapping by manually
configuring a new static domain ID for the isolated switch, or disable the static domain assignment, and
allow the switch to request a new domain ID after a fabric reconfiguration.
For example, two switches may be merging and one of the switches is already powered up, but the second
switch has a domain ID preconfigured. In this case, the switch that is powered up will have the priority
in keeping the conflicting domain ID. The presently powered-on switch, being the principal switch, will
assign a new domain ID to the new switch.
The E port could still isolate if the new switch has the domain ID configured as static, thus it would not
take any other domain ID except for the one configured. If this were the case, it would be necessary to
configure a new domain ID on the switch before the two switches could merge.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
In the above example, the TE port is carrying traffic for VSANs 1 and 333. This is an example of a
working TE port. There are no isolated VSANs in the list.
The following example shows the output of the show interface command, if one or more VSANs are
isolated:
switch# show interface fc2/14
fc2/14 is trunking
Hardware is Fibre Channel, WWN is 20:4e:00:05:30:00:63:9e
Port mode is TE
Speed is 2 Gbps
vsan is 2
Beacon is turned off
Trunk vsans (allowed active) (1-3,5)
Trunk vsans (operational) (1-3,5)
Trunk vsans (up) (2-3,5)
Trunk vsans (isolated) (1)
Trunk vsans (initializing) ()
475 frames input, 8982 bytes, 0 discards
0 runts, 0 jabber, 0 too long, 0 too short
0 input errors, 0 CRC, 3 invalid transmission words
0 address id, 0 delimiter
0 EOF abort, 0 fragmented, 0 unknown class
514 frames output, 7509 bytes, 16777216 discards
Received 30 OLS, 21 LRR, 18 NOS, 53 loop inits
Transmitted 68 OLS, 25 LRR, 28 NOS, 32 loop inits
In the above example, the TE port has one VSAN isolated. The reason for VSAN isolation can be
checked using the following command:
The command provides the same messages given by the show interface, in case of E port isolation. For
example:
switch# sh interface fc2/14 trunk vsan 1
fc2/15 is trunking
Vsan 1 is down (Isolation due to zone merge failure)
This output shows that VSAN 1 is isolated because of a zone merge error.
An alternative way to determine the cause of VSAN isolation, is to issue the following command:
switch#show port internal info interface fc2/14
The last few linst provide a description of the reason for VSAN isolation, for all the isolated VSANs.
switch# show port internal info int fc2/14
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
switch#
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
In the example, VSAN 7 is up, while two VSANs are isolated (VSAN 1 and 8, the first one because of
domain ID misconfiguration, and the second one because of VSAN misconfiguration).
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The message “Link_Failure” or “not connected” can happen if nothing is connected to the specific
interface (as in the case of a broken fiber), or if there is no bit synchronization between the switch
interface and the Nx port directly connected. (In the case of a broken fiber, if only the TX path from the
F port to the N port is broken, the switch interface will still have an operational Rx path, and so will still
obtain bit synchronization from the bit stream received from the N port. It will also be able to recognize
an incoming NOS from the N port and reply with an OLS. But because the transmitted OLS never
reaches the N port the R_T_TOV timer expires. In this scenario the status of the port will also show
"Link_Failure or not connected". )
The key difference between this case and the "no bit synchronization" case, is that the input and output
counts for OLS & NOS increment (as there is bit synchronization but no word synchronization). In such
a state, you can check that the Tx path from switch to the Rx input on N port interface is properly
connected. A faulty transmitter on the switch’s SFP or a faulty receiver on the N port’s SFP could also
cause the issue.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If, on the other hand, just the Rx path to the switch was broken and the TX path was intact, there would be no
bit synchronization. In this case, the switch would not attempt to move to the link initialization stage, and
therefore the OLS & NOS counters would never increment. Some possible causes of the problem could be
a faulty SFP, or a speed mismatch between the Fx port and the Nx port, in case speed autonegotiation is
disabled or doesn’t work properly with the specific HBA/Storage port.
One of the first steps in the effort to solve the incompatibility, is to verify the speed configuration on the
switch port. If the switch port is configured for a specific speed, configure the switch port for auto-speed
detection. If the port still does not come up or the speed autonegotiation was already in place, the next
possible step is to statically configure the speed of the port in order to match the one of the Nx port
directly connected.
In case this doesn’t solve the issue, and the port stays in the same status, the problem is probably a
physical issue. Verify all physical parts between and including the switch port, the SFP on the switch
port, and if used on the HBA, the HBA itself and the fiber connections.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Usually a port in this state cycles between the initializing state and the off-line state. If this the error,
verify that the switch port is configured as an F port. A port that is mistakenly set to be E port could
cause this error when connecting to an N port. If setting the switch port to autodetect mode still doesn’t
resolve the issue, try to statically configure the port type in order to match the Nx port behavior with
respect to loop or point-to-point initialization. There are some limited case in which the port type auto
negotiation could not work properly for incompatibility with some old HBAs. (The automatic detection
for the port mode is not applicable on an OSM module where at maximum one TE/E port can be configured
per quad.)
If after having statically configured the port mode, it still doesn’t come up, verify that the HBA is
working properly and possibly power-cycle the HBA (i.e. booting the server or resetting the adapter).
To check whether a FLOGI is issued to the switch during the Fx port initialization, the fcanalyzer can
be used.
In the example below, the fcanalyzer tool has been used with the necessary filtering to capture the FLOGI
sent by the N port. Refer to the Cisco MDS 9000 Family Configuartion Gude for more information.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the FLOGI is received by the switch, but the port is still not coming up, further investigation is needed
to determine if the FLOGI is rejected by the switch (i.e. still using the fcanalyzer) or the cause is a
misbehaving host, a broken fiber or a flappy connection between the end device and the Fx port on the
switch. (If an Nx port is considered faulty by the driver/firmware or the ASIC used on the HBA, it can be
configured to be in optical bypass. This results in the RX and TX paths being internally connected in the
loopback by the on-board circuitry. If this happens, the switch port connected to the faulty device will reach
bit and word synchronization with itself. If the port is configured in auto mode, this will cause the port to issue
an ELP and try to initialize as a TE/E Port, even if an end device is physically connected to that interface. In
this case a port reason code of isolation due to ELP failure, can show up even if an ISL is not present. To fix
the issue, one possible approach is to reset the HBA or changing it if the problem persists.)
An alternative way to get the same information and also the information about the configured speed is
to use the following command.
switch# show port internal info interface fc7/5
The second line of the long output generated by the command shows the administrative status of the port
(that reflect what configured by the administrator on the switch).
For example, issuing the command on a switch interface fc7/5 where a no shutdown command has been
issued and where the port mode has been configured to be auto-detected, with speed auto-negotiation
enabled and trunking capabilities enabled, the following output is displayed:
switch# show port internal info interface fc7/5
fc7/5 - if_index: 0x 1304000, phy_port_index: 0x84
Admin Config - state(up), mode(auto), speed(auto), trunk(on)
beacon(off), snmp trap(on), tem(false)
rx bb_credit(default), rx bb_credit multiplier(default)
rxbufsize(2112), encap(default), user_cfg_flag(0x1)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
description()
Operational Info - state(up), mode(F), speed(1 Gbps), trunk(off)
state reason(None)
phy port enable (1), phy layer (FC)
participating(1), port_vsan(1), null_vsan(0), fcid(0xef0300)
rx bb_credit multiplier(0), rx bb_credit(12)
current state [PI_FSM_ST_F_PORT_UP]
port_init_eval_flag(0x00003001), cfg wait for none
Mts node id 0x702
cnt_link_failure(54), cnt_link_success(53), cnt_port_up(4)
cnt_cfg_wait_timeout(0), cnt_port_cfg_failure(0), cnt_init_retry(0)
Port Capabilities -
Modes: E,TE,F,FL,TL,SD
Min Speed: 1000
Max Speed: 2000
Max Sourcable Pkt Size: 2112
Max Tx Bytes: 2112
Max Rx Bytes: 2112
Max Tx Buffer Credit: 255
Max Rx Buffer Credit: 12
Max Rx Buffer Credit (ISL): 12
Default Rx Buffer Credit: 12
Default Rx Buffer Credit(ISL): 12
Default Rx Buffer Credit Multiplier: 0
Rx Buffer Credit change not allowed
Max Private Devices: 63
Hw Capabilities: 0xb
Connector Type: 0x0
FCOT info -
Min Speed: 1000
Max Speed: 2000
Module Type: 8
Connector Type: 7
Gigabit Eth Compliance Codes: 0
FC Transmitter Type: 3
Vendor Name: CISCO-AGILENT
Vendor ID: 0:48:211
Vendor Part Num: QFBR-5796L
Vendor Revision Level:
Trunk Info -
trunk vsans (allowed active) (1)
If the configuration of the switch port is configured as auto, and the point-to-point link still comes up as
an FL port, verify that the HBA is configured as an NL port also.
Some HBAs support only NL mode. Verify the HBA capabilities with the vendor.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the server is still not able to see the storage after you have configured the default-zone policy to
“permit” on each switch in the fabric, check the VSAN configuration or the server and storage subsystem
configuration.
If there are configured active zones on the switch, the output of the command should look like:
switch# show zone active
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the output of this command doesn’t show any information, this means that no zoneset has been
activated in the fabric. If this is the case, you can use the two commands show zone or show zoneset to
determine whether a zone configuration has been issued on the switch. (Zone configuration, and
configuration changes do not get propagated to the other switches in the fabric, but only the changes to
the active zones or active zoneset get propagated. For this reason if zone information is configured on
one switch, it won’t appear in the configuration of other switches).
Assuming that the zone configuration has been issued on the switch, but no active zoneset is shown, the
next step is to enable the active zoneset in the specific VSAN to which the zoneset is supposed to belong.
To activate a zoneset in a defined VSAN, run the following command:
switch(config)# zoneset activate name ZonesetName vsan 1
The command must be issued on same switch the zone configuration took place. By copying the active
zone database on the local zone database, it is possible to modify and apply those changes to the active
zoneset on a different switch from the one initially used to issue the active zone configuration.
If no port shows as isolated, it means that all the switches in the fabric (or in the specific VSAN) share
the same active zone database. This is ensured by the merge and change protocols used whenever any of
the following occurs:
• two fabrics are connected
• a new ISL is configured in the fabric
• a new switch is connected to a pre-configured fabric
• changes are applied to the active zone database on any switch in the fabric
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
pwwn 20:00:00:e0:69:41:98:93
The output shows that the zone name was added incorrectly (names for both zones and zoneset are case
sensitive), creating a new zone called Zone-cc instead of zone-cc. Therefore, the storage pwwn has been
erroneously configured to belong to a zone in which that port is the only member. The pwwn of the
storage subsystem disappears from the output of show active zoneset command, because Zone-cc is not
be added to the active zoneset of VSAN2.
Use the show fcalias to show if and how aliases are configured.
switch# show fcalias vsan 1
fcalias name Alias2 vsan 1 pwwn 21:00:00:20:37:6f:db:dd
fcalias name Alias1 vsan 1 pwwn 21:00:00:20:37:9c:48:e5
Use the show zone member command to display all zones to which a member belongs using the FCID,
the fcalias, or the pwwn.
Use the show zone statistics command to display the number of control frames exchanged with other
switches.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The show zone internal vsan command shows the internal state of the zone server for a specific VSAN.
switch# sh zone internal vsan 1
VSAN: 1 default-zone: deny distribute: active only
E_D_TOV: 2000 R_A_TOV: 10000 F_S_TOV: 5000 Interop: Off
DBLock:-(F count:0) Ifindex Table Size:2
Full Zoning Database :
Zonesets:6 Zones:6 Aliases:0
Active Zoning Database :
Name: ZoneSet6 Zonesets:1 Zones:1 Aliases:0
TCAM Info :
cur_seq_num : 9, state : 0
add_reqs = 4, del_reqs = 0, entries_added = 0
Change protocol info :
local domain id = 102, ACA by 0xff
State = Idle, reply_cnt = 0, req_pending = 0
Remote domains :
Merge proto info :
i/f fc2/15 | State = Isolated | notify = 0x8 | - -
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
By recursively expanding the zone folders, the devices belonging to that zone will be listed in the left
side column of the Fabric Manager window, and they will be highlighted in the topology view on the
right side of the Fabric Manager window.
Troubleshooting VSANs
If VSANs are not configured properly, host devices will not be allowed to see storage devices configured
to belong to different VSANs.
Hosts and storage ports must belong to the same VSAN, and VSANs cannot overlap.
VSAN membership for a specific port can be verified using the following command:
switch# show vsan membership interface fc2/1
fc2/1
vsan:3
vsan 2 interfaces:
fc2/6 fc7/23 fc7/24
vsan 3 interfaces:
fc2/1 fc2/2 fc2/5
vsan 4 interfaces:
fc2/3 fc2/4
If the devices are on different switches, issue the show vsan membership command on both devices.
Then, verify that the trunks connecting the end switches are configured to transport the VSAN in
question. This is done by issuing the show interface command, to verify that the port is in trunk mode
and that the VSAN in question belongs to the trunk VSAN. Refer to the example below. If this is not the
case, refer to the Troubleshooting ISL Isolation section at the beginning of this chapter to determine how
to troubleshoot the connectivity issue.
switch# sh int fc2/14
fc2/14 is trunking
Hardware is Fibre Channel, WWN is 20:4e:00:05:30:00:63:9e
Port mode is TE
Speed is 2 Gbps
vsan is 2
Beacon is turned off
Trunk vsans (allowed active) (1-3,5)
Trunk vsans (operational) (1-3,5)
Trunk vsans (up) (2-3,5)
Trunk vsans (isolated) (1)
Trunk vsans (initializing) ()
475 frames input, 8982 bytes, 0 discards
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Use the following commands to get debug information for a FC module in an MDS 9120 or MDS 9140
switch:
show hardware internal errors
show hardware internal fc-mac2 port <port-num> link-status
show hardware internal fc-mac2 port <port-num> port-info
show hardware internal fc-mac2 port <port-num> misc-statistics
show hardware internal fc-mac2 port <port-num> status-reg
show hardware internal fc-mac2 port <port-num> state-info-log
show hardware internal fc-mac2 port <port-num> gbic-info
show hardware internal fc-mac2 port <port-num> statistics
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Use the following commands to get debug information for a FC module in an MDS 9120 or MDS 9140
switch:
show hardware internal fc-mac2 port <all-ports> error-statistics
show hardware internal fc-mac2 port <all-ports> interrupt-count
show hardware internal q-engine error-statistics
show hardware internal q-engine intr-counts
show hardware internal fwd-engine 0 error-statistics
show hardware internal fwd-engine 1 error-statistics
show hardware internal fwd-engine 0 interrupt-counts
show hardware internal fwd-engine 1 interrupt-counts
show hardware internal up-xbar 0 error-statistics
show hardware internal up-xbar 0 interrupt-counts
show hardware internal down-xbar 0 error-statistics
show hardware internal down-xbar 0 interrupt-counts
show process exceptionlog
C H A P T E R 4
Troubleshooting Switch Fabric Level Issues
This chapter describes switch fabric-level troubleshooting procedures and includes the following
sections:
• Troubleshooting Name Server Issues, page 4-1
• Troubleshooting FSPF Issues, page 4-6
• Troubleshooting Zoning Issues, page 4-14
Overview
The name server provides a way for N ports and NL ports to register and discover FibreChannel
attributes. Registrations may happen explicitly, as a consequence of a request of the Nx port, or
implicitly by the switch at FLOGI time. Once registered, the attributes are made available to other Nx
ports or other switches. A separate name server database is maintained for each VSAN. The name server
uses the Fibre Channel Common Transport protocol (FC-CT) to communicate with Nx ports and
represents itself as an N port at the well-known FCID 0xFFFFFC.
One instance of the name server process runs on each Cisco MDS 9000 Family switch. In a multi-switch
fabric configuration, instances running on different switches share information and create a distributed
database of Nx port attributes. The name server defines a set of attribute objects with the following
operations on those objects:
• Register Object
• Deregister Object
• Get Object
To troubleshoot name server problems, check the status of these three operations and verify the correct
distribution of attributes among name server instances within the fabric. These attributes include the
following:
• Port Type
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
• Port Identifier
• Port Name
• Node Name
• Port Symbolic Name
• Node Symbolic Name
• Class of Service
• FC-4 Type(s)
• Port IP Addresses
• Node IP Addresses
• Hard Address
• FC-4 Descriptor
• FC-4 Features
• Initial Process Associator
Step 1 From the CLI exec mode, enter the following command:
show interface fcx/x
This ensures that the fibre channel (FC) interface connected to the device in question is up and free of
any errors.
The system output might look like this:
switch# show int fc3/14
fc3/14 is up
Hardware is Fibre Channel
Port WWN is 20:8e:00:05:30:00:86:9e
Admin port mode is FX
Port mode is F, FCID is 0x780200 /* Operational State of the Port */
Port vsan is 99 /* This is the vsan */
Speed is 2 Gbps
Receive B2B Credit is 16
Receive data field size is 2112
Beacon is turned off
5 minutes input rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
5 minutes output rate 0 bits/sec, 0 bytes/sec, 0 frames/sec
1700 frames input, 106008 bytes, 0 discards
0 CRC, 0 unknown class
0 too long, 0 too short
2904 frames output, 364744 bytes, 0 discards
0 input OLS, 0 LRR, 0 NOS, 0 loop inits
1 output OLS, 1 LRR, 0 NOS, 0 loop inits
If the interface is not working correctly, check the cabling and the host or storage device interface for
faults. If the interface is working correctly, proceed to the next step.
Step 2 Verify that the device in question appears in the FLOGI database. To do this, enter the following
command:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the device in question appears in this output, skip to Step 8. If the device does not appear in the output,
go to the next step.
Step 3 From interface mode, shut down the FC interface connected to the device in question.
config terminal
interface fcx/x
shutdown
By shutting down the interface and bringing it back up, you can determine what happens when the
connected device tries to log in to the interface.
Step 5 Enter the following command to view the events that occurred on the interface after you enabled it again:
switch# show flogi internal event-history interface fc3/14
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The comments that follow each section of output explain the meaning of the output.
If the device logs in successfully, proceed to the next step. Otherwise, you may have a problem with the
device or its associated software.
Step 6 From interface mode, shut down the FC interface and issue a no shutdown after turning on the debug
described in the following steps.
Step 7 To watch the FLOGI process take place, enter the following command:
switch# debug fcns events register vsan 99
This command enables debug mode for nameserver registration. The system output looks like this:
switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# int fc3/14
switch(config-if)# no shut /* enable the port */
switch(config-if)# Feb 17 04:42:54 fcns: vsan 99: Created entry for port-id 27800
Feb 17 04:42:54 fcns: vsan 99: Got Entry for port-id 27800
Feb 17 04:42:54 fcns: vsan 99: Registered port-name 36a4078be0000021 for port-id 780200
Feb 17 04:42:54 fcns: vsan 99: Registered node-name 36a4078be0000020 for port-id 780200
/* The wwpn and FCID for the port, note that the bytes in the world wide name are reversed
*/
Feb 17 04:42:54 fcns: vsan 99: Registered cos 8 for port-id 780200
/* Class of Service */
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Feb 17 04:42:54 fcns: vsan 99: Registered port-type 1 for port-id 780200
/* Port Type */
Feb 17 04:42:54 fcns: vsan 99: Reading configuration for entry with port-name
36a4078be0000021, node-name 36a4078be0000020
Feb 17 04:42:54 fcns: vsan 99: No configuration present for this portname
Feb 17 04:42:54 fcns: vsan 99: No configuration present for this nodename
/* Port is now registered in nameserver, will send out RSCN to it */
Feb 17 04:42:54 fcns: vsan 99: Trying to send RSCN; affected port 780200
Feb 17 04:42:54 fcns: vsan 99: rscn timer started for port 780200
Feb 17 04:42:54 fcns: vsan 99: Saving new entry into pss
Feb 17 04:42:54 fcns: vsan 99: Sending sync message to the standby
Feb 17 04:42:54 fcns: vsan 99: sending accept response to 780200
/* RSCN was received by N/NL port */
Feb 17 04:42:55 fcns: vsan 99: Registered fc4-types for port-id 780200
Feb 17 04:42:55 fcns: vsan 99: Registered fc4-features for fc4_type 8 for port-id 780200
/* FC4 Type, type 8 FCP has been registered */
Additional lines like these will be listed if additional nameserver objects are registered
Step 8 From the CLI exec mode, enable FC name server (FCNS) debugging by entering the following
command:
debug fcns events register vsan x
If you are managing the switch over a telnet connection, enable terminal monitoring by entering the
terminal monitor command from the CLI exec mode.
The system output looks like this:
switch# show fcns database detail v 99
------------------------
VSAN:99 FCID:0x780200
------------------------
port-wwn (vendor) :21:00:00:e0:8b:07:a4:36 (QLogic) /* Port world wide name */
node-wwn :20:00:00:e0:8b:07:a4:36
class :3 /* Fibrechannel class of service */
node-ip-addr :0.0.0.0 /* IP Address */
ipa :ff ff ff ff ff ff ff ff
fc4-types:fc4_features:scsi-fcp:init /* Registered FC4 Types: example SCSI and
initiator */
symbolic-port-name :
symbolic-node-name :
port-type :N /* Fibrechannel port type (F,FL) */
port-ip-addr :0.0.0.0
fabric-port-wwn :20:8e:00:05:30:00:86:9e /* wwn of the switch port */
hard-addr :0x000000
Other attribute objects of the Nx port are registered one per register operation after the FLOGI process
is complete. The Nx port performs PLOGI to the well-known WWN of the Name Server, 0xFFFFFC.
The FC_CT Common Transport protocol uses Request and Accept messages to conduct transactions. To
verify that additional attributes are correctly registered and recorded in the database, you can use the
SAN-OS debug facility.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note The command show fcns database detail vsan X displays a detailed list of all devices registered in the
fabric.
Overview
To see all the correct FSPF information, as shown in the previous examples, the switches must be
configured correctly. If FSPF is misconfigured, then the switches will not reach the “two-way” state.
This can happen when:
• The switch fails to receive Hello in expected time (dead interval)
• The switch receives Hello from neighbor that does not contain the correct domain ID in the
Recipient Domain ID field.
• The switch receives Hello from neighbor with 0xFFFFFFFF in the Recipient Domain ID field.
Note Hellos are sent with 0xFFFFFFFF in neighbor field until switch learns its neighbor’s domain
ID.
• The switch receives Hello with incorrect Hello and dead intervals.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
1. Indicates that there is no second path to Domain 238, through Domain 1 switch2.
2. Indicates that there is no direct path to Domain 1 switch2; traffic must travel through 3 ISLs.
Step 3 To view the currently configured FSPF parameters on the ISL, enter the following command:
switch1# show fspf v 1 interfac fc1/16
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
1. Shows that the hello timer is not set to the default, so you should check the neighbor configuration
to make sure it matches.
2. Shows that FSPF is not in FULL state, indicating a problem.
Step 4 To determine the value of the Hello timer on the adjacent switch, enter the following command:
NEIGHBOR
switch2# show fspf v 1 interfac fc1/16
1. Shows that the neighbor FSPF Hello interval is set to the default (20 seconds).
2. Indicates that FSPF is not in FULL state, indicating a problem.
Step 5 An alternative to check the hello interval setting is the show run command.
switch1# show run
interface fc1/1
fspf hello-interval 5 vsan 1
no shutdown
This output indicates that the neighbor FSPF hello is set to the default. The default setting does not
display in the output from the show run command.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 1 To enable the debug output for identifying this condition, enter the following command:
switch1# debug fspf all
Step 2 To display the currently configured FSPF parameters on the interface, enter the following command:
switch1# show fspf v 1 interfac fc1/16
You should run this command on the local interface and on the switch at the other end of the ISL on
which the problem is occurring.
The system output looks like this:
switch1# show fspf v 1 interfac fc1/16
FSPF interface fc1/16 in VSAN 1
FSPF routing administrative state is active
Interface cost is 500
Timer intervals configured, Hello 20 s, Dead 95 s, Retransmit 5 s -----1
FSPF State is INIT -----2
x Statistics counters :
Number of packets received : LSU 0 LSA 0 Hello 2 Error packets 1
Number of packets transmitted : LSU 0 LSA 0 Hello 4 Retransmitted LSU 0
Number of times inactivity timer expired for the interface = 0
1. Indicates that the dead timer is not set to the default, so you should check the neighbor configuration.
2. Indicates that FSPF is not in full state, which indicates a problem.
Step 1 To display the currently configured region in a VSAN, enter the following command:
switch# show fspf vsan 99
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Switch1
Domain_ID
237
Port 1 Port 1
Index Index
0x00010001 0x00010000
Port 2 Port 2
Metric 1000 Metric 1000
Index Index
0x00010001 0x00010001
Port 4 Port 2
Index Index
0x00010003 Metric 1000 Metric 1000 0x00010001
Port 3 Port 4
Index Index
0x00010002 Domain_ID 0x00010003
238
91410
Switch5
For the purpose of this example, assume that all interfaces are located in VSAN 1.
Step 1 Verify that each path is in the FSPF database by entering the following command at the exec prompt:
Switch switch1# show fspf database
The following is the beginning of another switch’s LSR (Link State Record).
FSPF Link State Database for VSAN 1 Domain 237
LSR Type = 1
Advertising domain ID = 237 -----7
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following is the beginning of another switch’s LSR (Link State Record)
FSPF Link State Database for VSAN 1 Domain 238
LSR Type = 1
Advertising domain ID = 238
LSR Age = 1052
LSR Incarnation number = 0x80000013
LSR Checksum = 0xe294
Number of links = 2
NbrDomainId IfIndex NbrIfIndex Link Type Cost
------------------------------------------------------------------------------------------
-------
239 0x00010003 0x00010001 1 1000
1 0x00010002 0x00010003 1 1000
The following is the beginning of another switch’s LSR (Link State Record)
FSPF Link State Database for VSAN 1 Domain 239
LSR Type = 1
Advertising domain ID = 239
LSR Age = 1061
LSR Incarnation number = 0x80000086
LSR Checksum = 0x66ac
Number of links = 4
NbrDomainId IfIndex NbrIfIndex Link Type Cost
------------------------------------------------------------------------------------------
----
237 0x00010003 0x00010000 1 1000
238 0x00010001 0x00010003 1 1000
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
View the output from this command to verify that the interface is in FSPF “active state.” The system
output looks like this:
switch1# show fspf vsan 1 interface fc1/2
FSPF interface fc1/2 in VSAN 1
FSPF routing administrative state is active -----1
Interface cost is 1000 -----2
Timer intervals configured, Hello 20 s, Dead 80 s, Retransmit 5 s -----3
FSPF State is FULL -----4
Neighbor Domain Id is 1, Neighbor Interface index is 0x00010002 -----5
Statistics counters :
Number of packets received : LSU 46 LSA 24 Hello 103 Error packets 0
Number of packets transmitted : LSU 24 LSA 45 Hello 104 Retransmitted LSU 0
Number of times inactivity timer expired for the interface = 0
This displays the number of packets; Hellos should be received every 20 seconds.
1. Indicates that FSPF is active and is not disabled on this interface.
2. Indicates the cost of the path out this interface.
3. Identifies the configured FSPF timers for this interface, which must match on both sides.
4. Indicates Full State or Adjacent. Sent and received all database exchanges and required Acks. Port
is now ready to route frames.
5. Provides FSPF neighbor information.
Step 3 Verify that all FC routes are available by entering the following command:
switch1# show fspf internal route v 1
The next hop to (238) has two interfaces. This indicates that both paths will be used during load sharing.
Up to sixteen paths can be used by FSPF with a Cisco MDS 9000 Family switch.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note For all FSPF configuration statements and diagnostic commands, if the vsan keyword is not specified,
VSAN 1 is used by default. When making configuration changes or issuing diagnostic commands in a
multi-VSAN environment, be sure to explicitly specify the target VSAN by including the vsan keyword
in the statement or command.
Switch2 Switch3
In this example, two switches have the same zoneset name, and the same zone names, but different zone
members. As a result, the VSAN is isolated on the TE port that connects to two switches.
This issue can be resolved by doing one of the following:
1. Modify the zone members on both zonesets to match and elimiate conflict
2. Deactivate the zoneset on one of the switches and restart the zone merge process
3. Explicitly import or export a zoneset between the switches to synchronize them.
To identify this problem, follow these steps:
Step 1 Enter the following command to display the active zoneset configuration of the first switch:
Switch1# show zoneset active v 99
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 2 Enter the following command to display the active zoneset configuration of the second switch:
Switch2# show zoneset active v 99
Even though the zones have the same name, their respective members are different.
Step 3 Enter the following command to view information about the TE port:
Switch2# show int fc1/8
This command shows all the information about the interface. The system output looks like this:
Switch2# show int fc1/8
fc1/8 is trunking
Hardware is Fibre Channel
Port WWN is 20:08:00:05:30:00:5f:1e
Peer port WWN is 20:05:00:05:30:00:86:9e
Admin port mode is E, trunk mode is auto
Port mode is TE
Port vsan is 1
Speed is 2 Gbps
Receive B2B Credit is 255
Receive data field size is 2112
Beacon is turned off
Trunk vsans (admin allowed and active) (1,99)
Trunk vsans (up) (1)
Trunk vsans (isolated) (99)
Trunk vsans (initializing) ()
5 minutes input rate 120 bits/sec, 15 bytes/sec, 0 frames/sec
5 minutes output rate 88 bits/sec, 11 bytes/sec, 0 frames/sec
10845 frames input, 620268 bytes, 0 discards
0 CRC, 0 unknown class
0 too long, 0 too short
10842 frames output, 487544 bytes, 0 discards
3 input OLS, 4 LRR, 3 NOS, 0 loop inits
18 output OLS, 2 LRR, 14 NOS, 0 loop inits
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
From this output, you can see the VSAN is isolated due to a zone merge failure:
Step 5 To resolve the isolation problem, do one of the following:
• Change the membership of one of the zones to match the other of the same name.
• Discard one of the zonesets completely by either deactivating it, or by overwriting the active zoneset
on one switch using the import or export commands. This method is destructive to one of the active
zonesets.
For instructions about changing the membership of a zone, refer to the Cisco MDS 9000 Family
Configuration Guide.
Step 6 The following example shows the use of the export command:
In this example, the zoneset configuration is correct on switch1, so you would want to discard the zoneset
configuration on switch2. You get the same result by entering the zone import command from switch2.
Step 7 Import the active zoneset for VSAN 99 on interface fc1/8 by entering the following command:
Switch1# zone merge interface fc1/8 import vsan 99
Zoneset export initiated. check zone status
Step 8 Verify that VSAN 99 is no longer isolated by entering the following command:
Switch1# show int fc1/5 trunk v 99
fc1/5 is trunking
Vsan 99 is up, FCID is 0x780102
If a VSAN does not have an active zoneset, it automatically takes the active zoneset of the other merging
switch. So another way to solve this problem is by deactivating the active zoneset on switch2 by entering
the following command:
no zoneset activate name ZoneSet1 v 99
This removes the active zoneset on switch2, which will then automatically take the active zoneset from
switch1.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
When you explicitly import a zoneset for VSAN 1 from switch3 on switch4 over the isolated ISL, the
active zoneset is copied from switch3 to switch4. The zone databases are now synchronized, and the
VSAN is no longer isolated.
Step 1 Deactivate the zoneset configuration from the switch, as in the following example:
Caution This will disrupt traffic and cause the MDS 9000 switch to lose connectivity with the network.
Step 2 To confirm that the zoneset has been removed, enter the following command:
switch4(config)# exit
switch4# show zoneset active
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 4 To reactivate the connection to the zone to be merged, enter the following command:
switch4(config-if)#
switch4(config-if)# no shut
Step 5 To exit config mode and check the active zone sets, enter the following command:
switch4(config-if)# exit
switch4(config)# exit
switch4# show zoneset active
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
After deactivating the zoneset on switch4 and performing a shutdown followed by a no shutdown on the
ISL that connects it to switch3, the zone merge is processed again. Because switch3 has no active
zoneset, it learns the active zoneset from switch4 during the zone merge process.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
C H A P T E R 5
Troubleshooting IP Storage Issues
This chapter describes IP storage troubleshooting procedures and includes the following sections:
• Overview, page 5-1
• Troubleshooting IP Connections, page 5-2
• Troubleshooting FCIP Connections, page 5-5
• Troubleshooting iSCSI Issues, page 5-31
• Fine Tuning/Troubleshooting IPS iSCSI TCP Performance, page 5-44
Overview
Using open-standard, IP-based technology, the Cisco MDS 9000 Family IP storage module enables you
to extend the reach of Fibre Channel SANs. The switch can connect separated SAN islands together via
IP networks using FCIP, and allow IP hosts to access FC storage using the iSCSI protocol.
The IP Storage (IPS) services module allows you to use FCIP and iSCSI features. It supports the full
range of features available on other switching modules, including VSANs, security, and traffic
management. The IPS module can be used in any Cisco MDS 9000 Family switch and has eight Gigabit
Ethernet ports. Each port can run the FCIP and iSCSI protocols simultaneously.
FCIP transports Fibre Channel frames transparently over an IP network between two Cisco MDS 9000
Family switches or other FCIP standards-compliant devices (see Figure 5-1). Using the iSCSI protocol,
the IPS module provides IP hosts access to Fibre Channel storage devices. IP host-initiated iSCSI
commands are encapsulated in IP, and sent to an MDS 9000 IPS port. There, the commands are routed
from the IP network into a Fibre Channel network, and forwarded to the intended target.
MDS1 MDS2
FC
GE 2/8 IP GE 2/8
94218
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Troubleshooting IP Connections
If you suspect that all or part of your IP connection has failed, you can verify that by performing one or
more of the procedures in this section. Using these procedures, you can verify connectivity for IP,
subinterfaces/802.1q, EtherChannel, and VRRP for iSCSI.
Step 1 Perform a basic check of host reachability and network connectivity using the ping command. A sample
output of the ping command follows:
switch# ping 172.18.185.121
PING 172.18.185.121 (172.18.185.121): 56 data bytes
64 bytes from 172.18.185.121: icmp_seq=0 ttl=128 time=0.3 ms
64 bytes from 172.18.185.121: icmp_seq=1 ttl=128 time=0.1 ms
64 bytes from 172.18.185.121: icmp_seq=2 ttl=128 time=0.2 ms
64 bytes from 172.18.185.121: icmp_seq=3 ttl=128 time=0.2 ms
64 bytes from 172.18.185.121: icmp_seq=4 ttl=128 time=0.1 ms
64 bytes from 172.18.185.121: icmp_seq=5 ttl=128 time=0.1 ms
Step 2 Verify route to remote device using sh ip route, traceroute, and sh arp commands. A sample output of
the sh ip route command follows:
switch # sh ip route
A sample output of the traceroute command follows. The route is using int GigE, verified using the sh
arp command.
Another sample output of the traceroute command follows. This route is using int mgmt0, verified using
the sh arp command.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
A sample output of the clear ips arp command follows. You clear the arp cache to verify that the activity
you are viewing is the most current.
switch# sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.18.185.97 0 00d0.013b.380a ARPA mgmt0
Step 3 Use the show interface command to verify that the Gigabit Ethernet interface is up. A sample output of
the show interface command follows.
GigabitEthernet4/7 is up
Hardware is GigabitEthernet, address is 0005.3000.9f58
Internet address is 172.18.189.137/26
MTU 1500 bytes, BW 1000000 Kbit
Port mode is IPS
Speed is 1 Gbps
Beacon is turned off
5 minutes input rate 688 bits/sec, 86 bytes/sec, 0 frames/sec
5 minutes output rate 312 bits/sec, 39 bytes/sec, 0 frames/sec
156643 packets input, 16859832 bytes
0 multicast frames, 0 compressed
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
switch# sh ip route
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS1 MDS2
FC
GE 2/8 IP GE 2/8
94218
FC1/14 10.10.10.2/24 Network 10.10.11.2/24 FC1/1
FC
HBA
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The interface FCIP can be any number between 1 – 255 and does not need to be the same as the profile
number. In this example the same number is used for simplicity.
Step 9 Specify a profile to use.
MDS1(config-if)# use-profile 28
The interface FCIP will use the Local FCIP profile . The FCIP profile binds the interface FCIP to the
physical Gigabit Ethernet port and configures the TCP settings used by the interface FCIP.
MDS1(config-if)# peer-info ipaddr 10.10.11.2
The IP address in this example indicates the remote endpoint IP address of the FCIP tunnel.
MDS1(config-if)# no shut
MDS1(config-if)# end
The output from issuing the show run command displays the default values in the following example.
MDS1# show run
vsan database
vsan 2 name grumpy_02
interface fcip28
no shutdown
use-profile 28
peer-info ipaddr 10.10.11.2
The static route must be set for FCIP tunnels. This route could also be ip route 10.10.11.0
255.255.255.0 int gig 2/8.
ips heartbeat
ips hapreset
ips boot
interface GigabitEthernet2/8
ip address 10.10.10.2 255.255.255.0
(This is the IP address used by the FCIP profile.)
no shutdown
The following example shows the configuration of MDS2 with debug mode activated. To activate debug
mode for this situation, run the debug ips flow fcip command on a separate terminal.
MDS2(config)# fcip profile 28
Mar 10 21:41:04 ips: Dequeued mts msg MTS_OPC_IPS_FCIP_CMI_REQUEST(mts opc 3321, msg id
32222)
Mar 10 21:41:04 ips: Create Entity 28
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS2(config-profile)# exit
MDS2(config-if)# use-profile 28
Mar 10 21:42:23 ips: Dequeued mts msg MTS_OPC_IPS_FCIP_CMI_REQUEST(mts opc 3321, msg id
32480)
Mar 10 21:42:23 ips: FCIP28: Process tunnel configuration event
Mar 10 21:42:23 ips: FCIP28: Change Entity-id from 0 to 28
Mar 10 21:42:23 ips: FCIP: Optimal IF lookup for GigabitEthernet2/8 is GigabitEthernet2/8
Mar 10 21:42:23 ips: FCIP28: bind with GigabitEthernet2/8 (phy GigabitEthernet2/8)
Mar 10 21:42:23 ips: FCIP28: Queueing bind tunnel to src if event to tunnel FSM resource:
0
Mar 10 21:42:23 ips: Locked fcip_if_fsm for MTS_OPC_IPS_FCIP_CMI_REQUEST(msg id 32480)
Mar 10 21:42:23 ips: FCIP28: Send bind for GigabitEthernet2/8 to PM (phy
GigabitEthernet2/8)
Mar 10 21:42:23 ips: FCIP28: add to run-time pss
Mar 10 21:42:23 ips: FCIP28: log: 2087000 phy: 2087000 state: 0 syslog: 0
Mar 10 21:42:23 ips: Dequeued mts msg MTS_OPC_IPS_CFG_FCIP_IF(mts opc 1905, msg id 7304)
Mar 10 21:42:23 ips: Hndlr MTS_OPC_IPS_CFG_FCIP_IF (mts_opc 1905 msg_id 7304)
Mar 10 21:42:23 ips: FCIP28: Got a tunnel param pull request from LC
Mar 10 21:42:23 ips: Added to pending queue event-id [29] event-cat [2]
Mar 10 21:42:23 ips: FCIP28: Queueing Process a Pull Request event to Pending queue
resource: 0
Mar 10 21:42:23 ips: Dequeued mts msg MTS_OPC_PM_FCIP_BIND(mts opc 335, msg id 32495)
Mar 10 21:42:23 ips: Hndlr MTS_OPC_PM_FCIP_BIND (mts_opc 335 msg_id 32495)
Mar 10 21:42:23 ips: FCIP28: Success received from PM for bind to GigabitEthernet2/8 (phy
GigabitEthernet2/8)
Mar 10 21:42:23 ips: FCIP28: Bind-resp event processing bind...
Mar 10 21:42:23 ips: FCIP28: add to run-time pss
Mar 10 21:42:23 ips: FCIP28: log: 2087000 phy: 2087000 state: 1 syslog: 0
Mar 10 21:42:23 ips: FCIP28: Last reference....
Mar 10 21:42:23 ips: FCIP28: Update the tunnel param and save to PSS
Mar 10 21:42:23 ips: FCIP28: add to admin pss
Mar 10 21:42:23 ips: FCIP28: add to run-time pss
Mar 10 21:42:23 ips: FCIP28: log: 2087000 phy: 2087000 state: 1 syslog: 0
Mar 10 21:42:23 ips: Unlocked fcip_if_fsm for MTS_OPC_IPS_FCIP_CMI_REQUEST(msg id 32480)
Mar 10 21:42:23 ips: Dequeued pending queue msg event_id [29] cat [2]
Mar 10 21:42:23 ips: (ips_demux) Mts Opcode is 1905, id is 7304
Mar 10 21:42:23 ips: FCIP28: Processing Pull Config Request
Mar 10 21:42:23 ips: FCIP28: Bound to entity 28 port: 3225 ip: 10.10.11.2
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS2(config-if)#
MDS2(config-if)# no shut
MDS2(config-if)# Mar 10 21:43:32 ips: Dequeued mts msg
MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE(mts opc 3114, msg id 32737)
Mar 10 21:43:32 ips: Hndlr MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE (mts_opc 3114 msg_id
32737)
Mar 10 21:43:32 ips: Dequeued mts msg MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE(mts opc
3114, msg id 32778)
Mar 10 21:43:32 ips: Hndlr MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE (mts_opc 3114 msg_id
32778)
Mar 10 21:43:32 ips: Dequeued mts msg MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE(mts opc
3114, msg id 32783)
Mar 10 21:43:32 ips: Hndlr MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE (mts_opc 3114 msg_id
32783)
The following example shows the debug output from the supervisor of the FCIP tunnel.
MDS2(config)# int fcip 28
MDS2(config-if)# no shut
MDS2(config-if)# Mar 10 22:59:46 ips: fu_priority_select: - setting fd[3] for select call
- found data in FU_PSEL_Q_CAT_MTS queue, fd(3), usr_q_info(1)
Mar 10 22:59:46 ips: fu_priority_select_select_queue: round credit(0)
Mar 10 22:59:46 ips: curr_q - FU_PSEL_Q_CAT_CQ, usr_q_info(3), priority(4), credit(0),
empty
Mar 10 22:59:46 ips: Starting a new round
Mar 10 22:59:46 ips: fu_priority_select: returning FU_PSEL_Q_CAT_MTS queue, fd(3),
usr_q_info(1)
Mar 10 22:59:46 ips: Dequeued mts msg MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE(mts opc
3114, msg id 47540)
Mar 10 22:59:46 ips: ips_mts_hdlr_pm_logical_port_state_change_range:
Mar 10 22:59:46 ips: Hndlr MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE (mts_opc 3114 msg_id
47540)
Mar 10 22:59:46 ips: fu_fsm_execute_all: match_msg_id(0), log_already_open(0)
Mar 10 22:59:46 ips: fu_fsm_execute_all: null fsm_event_list
Mar 10 22:59:46 ips: fu_fsm_engine: mts msg
MTS_OPC_PM_LOGICAL_PORT_STATE_CHANGE_RANGE(msg_id 47540) dropped
Mar 10 22:59:46 ips: fu_priority_select: - setting fd[3] for select call - found data in
FU_PSEL_Q_CAT_MTS queue, fd(3), usr_q_info(1)
Mar 10 22:59:46 ips: fu_priority_select_select_queue: round credit(6)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following example shows the debug output from the IPS module of the FCIP tunnel.
MDS2# attach module 2
module-2# debug ips fcip fsm port 8
(This is the Gigabit Ethernet port 2/8.)
Mar 13 19:18:19 port8: 2700:FCIP28: Received new TCP connection from peer:
10.10.10.2:65455
Mar 13 19:18:19 port8: 2701:FCIP: (fcip_de_create): DE = 0xdc02ca40
Mar 13 19:18:19 port8: 2702:FCIP28: Create a DE 0xdc02ca40 for this tunnel
Mar 13 19:18:19 port8: 2703:FCIP28: Bind the DE 0xdc02ca40 [1] to tunnel LEP 0x801ebac0
Mar 13 19:18:19 port8: 2704:FCIP28: Bind DE 1 to TCP-hdl 0xdc489800
Mar 13 19:18:19 port8: 2705:FCIP28: Bind DE 1 to eport 0x801eaaa0
Mar 13 19:18:19 port8: 2706:FCIP28: bind de 1 in eport 0x801eaaa0, hash = 1 num-conn: 2
Mar 13 19:18:19 port8: 2707:FCIP28: Received new TCP connection from peer:
10.10.10.2:65453
Mar 13 19:18:19 port8: 2708:FCIP: (fcip_de_create): DE = 0xdc02cb40
Mar 13 19:18:19 port8: 2709:FCIP28: Create a DE 0xdc02cb40 for this tunnel
Mar 13 19:18:19 port8: 2710:FCIP28: Bind the DE 0xdc02cb40 [2] to tunnel LEP 0x801ebac0
Mar 13 19:18:19 port8: 2711:FCIP28: Bind DE 2 to TCP-hdl 0xdc488800
Mar 13 19:18:19 port8: 2712:FCIP28: Bind DE 2 to eport 0x801eaaa0
Mar 13 19:18:19 port8: 2713:FCIP28: bind de 2 in eport 0x801eaaa0, hash = 2 num-conn: 2
Mar 13 19:18:19 port8: 2714:FCIP28: Send LINK UP to SUP
Mar 13 19:18:20 port8: 2715:FCIP28: *** Received eisl frame in E mode
Mar 13 19:18:20 port8: 2716:FCIP28: SUP-> Set trunk mode: 2
Mar 13 19:18:20 port8: 2717:FCIP28: Change the operational mode to TRUNK
Mar 13 19:18:20 port8: 2718:FCIP28: Tunnel bringup debounce timer callbeck, try to bring
up tunnel
Mar 13 19:18:20 port8: 2719:FCIP28: Tunnel is already in oper UP state, don't try to
bring up again...
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Use the show fcip profile command to verify that the configuration of the profiles are correct. The IP
address and TCP port are the ports to listen on, and both are adjustable in the FCIP profile. The example
below displys all default values that are adjustable while configuring the FCIP profile.
MDS1# show fcip profile
-------------------------------------------------------------------------------
ProfileId Ipaddr TcpPort
-------------------------------------------------------------------------------
28 10.10.10.2 3225
MDS1# show fcip profile 28
FCIP Profile 28
Listen Port is 3225
TCP parameters
SACK is disabled
PMTU discover is enabled, reset timeout is 3600 sec
Keep alive is 60 sec
Minimum retransmission timeout is 100 ms
Maximum number of re-transmissions is 4
Advertised window size is 64 KB
Use the show interface fcip command to verify that the interface FCIP tunnel is established and that
traffic is passing through.
MDS1# show interface fcip 28
FCIP28 is trunking
Hardware is GigabitEthernet
Port WWN is 20:5e:00:05:30:00:59:de
Peer port WWN is 20:5e:00:0b:5f:d5:9f:c0
Admin port mode is auto, trunk mode is on
Port mode is TE
(The FCIP tunnel will be either E (ISL or TE (EISL) passing through multiple VSANs.)
vsan is 1
Trunk vsans (allowed active) (1-2)
Trunk vsans (operational) (1-2)
Trunk vsans (up) (1-2)
Trunk vsans (isolated) ()
Trunk vsans (initializing) ()
Using Profile id 28 (interface GigabitEthernet2/8)
(This is the FCIP profile and the Gigabit Ethernet being used by the FCIP tunnel.)
Peer Information
Peer Internet address is 10.10.11.2 and port is 3225
(This is the remote end point’s IP address and listening port.)
Special Frame is disabled
(The Special Frame for verification of a remote MDS is not being used.)
Maximum number of TCPconnections is 2
(The default is 2 TCP connection being used, one for class F and other for class 2 and 3.)
Time Stamp is disabled
(The timestamp can be activated under the interface FCIP.)
B-port mode disabled
TCP Connection Information
2 Active TCP connections
Control connection: Local 10.10.10.2:3225, Remote 10.10.11.2:65519
(The above is class F traffic.)
Data connection: Local 10.10.10.2:3225, Remote 10.10.11.2:65521
(The above is class 2,3 traffic.)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
-------------------------------------------------------------------------------
Interface Vsan Admin Admin Status Oper Profile Port-channel
Mode Trunk Mode
Mode
-------------------------------------------------------------------------------
fcip28 1 auto on trunking TE 28 --
-------------------------------------------------------------------------------
Interface Input (rate is 5 min avg) Output (rate is 5 min avg)
----------------------------- -----------------------------
Rate Total Rate Total
Mbits/s Frames Mbits/s Frames
-------------------------------------------------------------------------------
fcip28 18 0 18 0
(This is the frames that averaged over 5 minutes and the total count of frames since the last clear
counters command was issued, or since the last tunnel up.)
Verify default 2 tcp connections are established for each fcip tunnel configured, one for control traffic
and one for data traffic
MDS1# show ips stats tcp interface gigabitethernet 2/8
TCP Statistics for port GigabitEthernet2/8
Connection Stats
6 active openings, 8 accepts
6 failed attempts, 0 reset received, 8 established
Segment stats
295930 received, 1131824 sent, 109 retransmitted
(Excessive retransmits indicate possible core drops and/or that the TCP window size should be adjusted.)
0 bad segments received, 0 reset sent
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
You can use the following command to verify that traffic is incrementing on Gigabit Ethernet port of the
FCIP tunnel.
MDS1# show ips stats mac interface gigabitethernet 2/8
Ethernet MAC statistics for port GigabitEthernet2/8
Hardware Transmit Counters
1074898 frame 1095772436 bytes
0 collisions, 0 late collisions, 0 excess collisions
0 bad frames, 0 FCS error, 0 abort, 0 runt, 0 oversize
Hardware Receive Counters
33488196 bytes, 298392 frames, 277 multicasts, 16423 broadcasts
0 bad, 0 runt, 0 CRC error, 0 length error
0 code error, 0 align error, 0 oversize error
Software Counters
298392 received frames, 1074898 transmit frames
0 frames soft queued, 0 current queue, 0 max queue
0 dropped, 0 low memory
Traffic statistics can be verified on the internal ASIC chip on each Gigabit Ethernet port.
MDS1# show ips stats flamingo interface gigabitethernet 2/8
Flamingo ASIC Statistics for port GigabitEthernet2/8
Hardware Egress Counters
2312 Good, 0 bad protocol, 0 bad header cksum, 0 bad FC CRC
(Good frames and CRC error frames can be monitored.)
Hardware Ingress Counters
(Verify good increments on the active tunnel.)
2312 Good, 0 protocol error, 0 header checksum error
0 FC CRC error, 0 iSCSI CRC error, 0 parity error
Software Egress Counters
2312 good frames, 0 bad header cksum, 0 bad FIFO SOP
0 parity error, 0 FC CRC error, 0 timestamp expired error
0 unregistered port index, 0 unknown internal type
0 RDL, 0 RDL too big RDL, 0 TDL ttl_1
3957292257 idle poll count, 0 loopback, 0 FCC PQ, 0 FCC EQ
Flow Control: 0 [0], 0 [1], 0 [2], 0 [3]
Software Ingress Counters
2312 Good frames, 0 header cksum error, 0 FC CRC error
0 iSCSI CRC error, 0 descriptor SOP error, 0 parity error
0 frames soft queued, 0 current Q, 0 max Q, 0 low memory
0 out of memory drop, 0 queue full drop
0 RDL, 0 too big RDL drop
Flow Control: 0 [0], 0 [1], 0 [2], 0 [3]
On the next few pages are screen captures taken with Ethereal, of TCP connection being established, and
FCIP tunnels. Note that FCIP tunnel activation is the same as an FC EISL becoming active (such as ELP,
ESC, and EFP). The following traces were captured after configuration on both MDS 9000 Family
switches, and the last “no shutdown” was entered on switch MDS1. All settings are default (for
example, SACK is disabled, the TCP window is set to 64K).
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Figure 5-4 shows more of the trace, with frame 13 being the first FCIP frame. This frame carries the FC
Standard ELP.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Figure 5-5 shows the FC portion of the EISL initialization over the FCIP tunnel.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
GE 2/1 GE 2/1
10.10.10.2/24 10.10.10.2/24
Fcip profile 21
ip address 10.10.10.2 Fcip profile 1
ip address 10.10.8.2
Interface fcip 1
Interface fcip 23 use-proficle 1
use-proficle 21 peer-info ipaddr 10.10.10.2
peer-info ipaddr 10.10.8.2
GE 2/1
MDS1
IP 10.10.11.2/24
Network
Fcip profile 1
ip address 10.10.11.2
Interface fcip 1
use-proficle 1
Interface fcip 28 peer-info ipaddr 10.10.10.2
use-proficle 21
peer-info ipaddr 10.10.7.2
GE 2/1
10.10.7.2/24
Interface fcip 21
use-proficle 21 Fcip profile 1
peer-info ipaddr 10.10.11.2 ip address 10.10.7.2
Interface fcip 1
use-proficle 1
94222
peer-info ipaddr 10.10.10.2
The following example shows the configuration of switch MDS1 for three tunnels from one Gigabit
Ethernet port.
MDS1(config)# fcip profile 21
MDS1(config-profile)# ip address 10.10.10.2
MDS1(config-profile)# exit
MDS1(config)# interface fcip 21
MDS1(config-if)# use-profile 21
MDS1(config-if)# peer-info ipaddr 10.10.11.2
MDS1(config-if)# no shut
MDS1(config-if)# exit
Now the interface FCIP is created for the second tunnel. The same FCIP profile is used for this example.
A separate FCIP profile can be used for each interface FCIP if desired.
MDS1(config-if)#
MDS1(config-if)# int fcip 23
MDS1(config-if)# use-profile 21
MDS1(config-if)# peer-info ipaddr 10.10.8.2
MDS1(config-if)# no shut
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS1(config-if)# exit
MDS1(config)#
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following example shows a configuration error when using multiple FCIP profiles on one physical
Gigabit Ethernet port.
MDS2(config)# fcip profile 21
MDS2(config-profile)# ip address 10.10.11.2
error: fcip another profile exists with same port & ip
(Multiple FCIP profiles can be used on one physical Gigabit Ethernet port, but each profile must have a
different listening port.)
MDS2(config-profile)# port ?
<1-65535> Profile TCP Port
MDS2(config-profile)# port 32
(Change the TCP listening port on the profile. The default is 3225.)
MDS2(config-profile)# ip address 10.10.11.2
(The IP address for the Gigabit Ethernet port 2/1 is now accepted, and two FCIP profiles are using the
same Gigabit Ethernet port.)
MDS2(config-profile)# end
MDS2# show fcip profile 21
FCIP Profile 21
Internet Address is 10.10.11.2 (interface GigabitEthernet2/1)
Listen Port is 32
(This is a new TCP listen port.)
TCP parameters
SACK is disabled
PMTU discover is enabled, reset timeout is 3600 sec
Keep alive is 60 sec
Minimum retransmission timeout is 300 ms
Maximum number of re-transmissions is 4
Advertised window size is 64 KB
MDS2# show fcip profile 28
FCIP Profile 28
Internet Address is 10.10.11.2 (interface GigabitEthernet2/1)
Listen Port is 3225
(This is the default listen port.)
TCP parameters
SACK is disabled
PMTU discover is enabled, reset timeout is 3600 sec
Keep alive is 60 sec
Minimum retransmission timeout is 300 ms
Maximum number of re-transmissions is 4
Advertised window size is 64 KB
The following example shows a configuration error when bringing a tunnel up on the selected port. This
could be either an FCIP profile issue or an interface FCIP issue. Both sides must be configured correctly.
MDS2(config)# fcip profile 21
MDS2(config-profile)# port 13
(Change the TCP listen port on switch MDS2.)
MDS2(config-profile)# end
MDS2(config)# int fcip 21
MDS2(config-if)# passive-mode
(Put interface FCIP 21 in passive mode to guarantee MDS1 initiates a TCP connection.)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following example shows the interface FCIP is administratively shut down. The debug output is
from the IPS module.
Module-2# debug ips fcip fsm port 1
module-2# Mar 14 21:32:27 port1: 1:FCIP21: Create tunnel with ifindex: a000014
Mar 14 21:32:27 port1: 2:FCIP21: Get the peer info from the SUP-IPS-MGR
Mar 14 21:32:27 port1: 3:FCIP21: SUP-> Disable tunnel: already in disable state
Mar 14 21:32:27 port1: 4:FCIP21: SUP-> Set Port mode 1
Mar 14 21:32:27 port1: 5:FCIP21: SUP-> Set port index: 21
Mar 14 21:32:27 port1: 6:FCIP21: Try to Bring UP the Tunnel
Mar 14 21:32:27 port1: 7:FCIP21: Tunnel in admin down state
(The tunnel needs no shut down on the interface FCIP.)
Mar 14 21:32:27 port1: 8:FCIP21: SUP-> Set port VSAN: 1
Mar 14 21:32:27 port1: 9:FCIP21: Try to Bring UP the Tunnel
Mar 14 21:32:27 port1: 10:FCIP21: Tunnel in admin down state
Mar 14 21:32:27 port1: 11:FCIP21: SUP-> Set port WWN: 0x2042000b5fd59fc0
Mar 14 21:32:27 port1: 12:FCIP21: Try to Bring UP the Tunnel
Mar 14 21:32:27 port1: 13:FCIP21: Tunnel in admin down state
(The tunnel needs no shut down on the interface FCIP.)
Mar 14 21:32:27 port1: 14:FCIP21: SUP-> Set trunk mode: 1
Mar 14 21:32:27 port1: 15:FCIP21: SUP-> Set source IF: 2080000
Mar 14 21:32:27 port1: 16:FCIP21: Try to Bring UP the Tunnel
Mar 14 21:32:27 port1: 17:FCIP21: Tunnel in admin down state
Mar 14 21:32:27 port1: 18:FCIP21: SUP-> Switch WWN: 0x2000000b5fd59fc0
Mar 14 21:32:27 port1: 19:FCIP21: Try to Bring UP the Tunnel
Mar 14 21:32:27 port1: 20:FCIP21: Tunnel in admin down state
Mar 14 21:32:27 port1: 21:FCIP21: SUP-> Response to SB's pull all tunnel info
Mar 14 21:32:27 port1: 22:FCIP21: SUP-> Set peer port: 3225 current port: 3225
Mar 14 21:32:27 port1: 23:FCIP21: peer port has same value, do nothing
Mar 14 21:32:27 port1: 24:FCIP21: Set number of tcp connection 2
Mar 14 21:32:27 port1: 25:FCIP21: SUP-> Set Local listen IP: 10.10.11.2 current ip
0.0.0.0
Mar 14 21:32:27 port1: 26:FCIP21: SUP-> Set Local listen Port: 3225 current port 3225
Mar 14 21:32:27 port1: 27:FCIP21: SUP-> Enable PMTU Discovery, timeout 3600
Mar 14 21:32:27 port1: 28:FCIP21: SUP-> Set round-trip time to 300 ms. Current value 100
ms
Mar 14 21:32:27 port1: 29:FCIP21: SUP-> Set keep-alive time to 60 sec. current value 60
sec
Local MDS trying to connect to remote end point on port 13 and remote end point set to
default listen port 3225
MDS2# show int fcip 21
fcip21 is down (Link failure or not-connected)
Hardware is GigabitEthernet
Port WWN is 20:42:00:0b:5f:d5:9f:c0
Admin port mode is auto, trunk mode is on
vsan is 1
Using Profile id 21 (interface GigabitEthernet2/1)
Peer Information
Peer Internet address is 10.10.10.2 and port is 13
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
In the following example, passive mode is set on both sides of the FCIP tunnel.
module-2# Mar 14 23:49:06 port1: 1870:FCIP21: SUP-> Set Port mode 1
Mar 14 23:49:06 port1: 1871:FCIP21: SUP-> Port VSAN (1) already set to same value
Mar 14 23:49:06 port1: 1872:FCIP21: SUP-> Trunk mode (1) already set to same value
Mar 14 23:49:06 port1: 1873:FCIP21: SUP-> Enable tunnel ADMIN UP
Mar 14 23:49:06 port1: 1874:FCIP21: Try to Bring UP the Tunnel
Mar 14 23:49:06 port1: 1875:FCIP21: Start TCP listener with peer: 10.10.10.2:3225
Mar 14 23:49:06 port1: 1876:FCIP: Create a new listener object for 10.10.11.2:3225
Mar 14 23:49:06 port1: 1877:FCIP: Create FCIP Listener with local info: 10.10.11.2:3225
Mar 14 23:49:06 port1: 1878:FCIP21: Passive mode set, don't initiate TCP connection
(A TCP connection will not be established when passive mode is set. The Gigabit Ethernet port will only
listen.)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The following example shows a time stamp acceptable difference failure, or no NTP server connected to
synchronize clocks. When using time stamps, the MDS switch must be a synchronized clock. NTP is
configurable on the MDS 9000 switch.
MDS2(config)# int fcip 21
MDS2(config-if)# time-stamp
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
module-2#
Jan 14 15:25:38 port1: 857314:FCIP21: SUP-> Set Port mode 1
Jan 14 15:25:38 port1: 857315:FCIP21: SUP-> Port VSAN (1) already set to same value
Jan 14 15:25:38 port1: 857316:FCIP21: SUP-> Trunk mode (1) already set to same value
Jan 14 15:25:38 port1: 857317:FCIP21: SUP-> Enable tunnel ADMIN UP
Jan 14 15:25:38 port1: 857318:FCIP21: Try to Bring UP the Tunnel
Jan 14 15:25:38 port1: 857319:FCIP21: Start TCP listener with peer: 10.10.10.2:3225
Jan 14 15:25:38 port1: 857320:FCIP: Create a new listener object for 10.10.11.2:3225
Jan 14 15:25:38 port1: 857321:FCIP: Create FCIP Listener with local info: 10.10.11.2:3225
Jan 14 15:25:38 port1: 857322:FCIP21: Create a DE 0xd802cd00 for this tunnel
Jan 14 15:25:38 port1: 857323:FCIP21: Bind the DE 0xd802cd00 [1] to tunnel LEP 0x80111570
Jan 14 15:25:38 port1: 857324:FCIP21: Start the active connection [1] to 10.10.10.2:3225
Jan 14 15:25:38 port1: 857325:FCIP21: Create a DE 0xd802db40 for this tunnel
Jan 14 15:25:38 port1: 857326:FCIP21: Bind the DE 0xd802db40 [2] to tunnel LEP 0x80111570
Jan 14 15:25:38 port1: 857327:FCIP21: Start the active connection [2] to 10.10.10.2:3225
Jan 14 15:25:38 port1: 857328:FCIP21: Active Connect creation SUCCEEDED [1]
Jan 14 15:25:38 port1: 857329:FCIP21: Bind DE 1 to TCP-hdl 0xd8072c00
Jan 14 15:25:38 port1: 857330:FCIP21: Setup for Special Frame handling: I'm Originator
(This begins the Special Frame setup of the Originator.)
Jan 14 15:25:38 port1: 857331:FCIP21: Send the SF as Originator & wait for response
(The Special Frame is sent.)
Jan 14 15:25:38 port1: 857332:FCIP21: Setup timer to wait for SF
Jan 14 15:25:38 port1: 857333:FCIP21: Active Connect creation SUCCEEDED [2]
(The Special Frame is correctly configured with the WWN of the remote MDS 9000 switch.)
Jan 14 15:25:38 port1: 857334:FCIP21: Bind DE 2 to TCP-hdl 0xd8072000
Jan 14 15:25:38 port1: 857335:FCIP21: Setup for Special Frame handling: I'm Originator
Jan 14 15:25:38 port1: 857336:FCIP21: Send the SF as Originator & wait for response
Jan 14 15:25:38 port1: 857337:FCIP21: Setup timer to wait for SF
Jan 14 15:25:38 port1: 857338:FCIP21: processing SF frame, I'm Originator
Jan 14 15:25:38 port1: 857339:FCIP21: Bind DE 1 to eport 0x80110550
Jan 14 15:25:38 port1: 857340:FCIP21: bind de 1 in eport 0x80110550, hash = 1 num-conn: 2
Jan 14 15:25:38 port1: 857341:FCIP21: processing SF frame, I'm Originator
Jan 14 15:25:38 port1: 857342:FCIP21: Bind DE 2 to eport 0x80110550
Jan 14 15:25:38 port1: 857343:FCIP21: bind de 2 in eport 0x80110550, hash = 2 num-conn: 2
Jan 14 15:25:38 port1: 857344:FCIP21: Send LINK UP to SUP
Jan 14 15:25:39 port1: 857345:FCIP21: SUP-> Set trunk mode: 2
Jan 14 15:25:39 port1: 857346:FCIP21: Change the operational mode to TRUNK
Jan 14 15:25:39 port1: 857347:FCIP21: *** Received non-eisl frame in TE mode 64 64
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Hardware is GigabitEthernet
Port WWN is 20:42:00:0b:5f:d5:9f:c0
Peer port WWN is 20:42:00:05:30:00:59:de
Admin port mode is auto, trunk mode is on
Port mode is TE
vsan is 1
Trunk vsans (allowed active) (1-2)
Trunk vsans (operational) (1-2)
Trunk vsans (up) (1-2)
Trunk vsans (isolated) ()
Trunk vsans (initializing) ()
Using Profile id 21 (interface GigabitEthernet2/1)
Peer Information
Peer Internet address is 10.10.10.2 and port is 3225
Special Frame is enabled
(The Special Frame is enabled. It is used for security to verify that the tunnel remote end point is the
correct pwwn of the switch.)
Peer switch WWN is 20:00:00:05:30:00:59:de
(This is the peer WWN of the remote switch. The pWWN of the switch can be found using the show
wwn switch command.)
Maximum number of TCP connections is 2
Time Stamp is enabled, acceptable time difference 3000 ms
B-port mode disabled
TCP Connection Information
2 Active TCP connections
Control connection: Local 10.10.11.2:64792, Remote 10.10.10.2:3225
Data connection: Local 10.10.11.2:64794, Remote 10.10.10.2:3225
372 Attempts for active connections, 345 close of connections
TCP Parameters
Path MTU 1500 bytes
Current retransmission timeout is 300 ms
Round trip time: Smoothed 10 ms, Variance: 5
Advertized window: Current: 64 KB, Maximum: 64 KB, Scale: 1
Peer receive window: Current: 64 KB, Maximum: 64 KB, Scale: 1
Congestion window: Current: 2 KB, Slow start threshold: 1048560 KB
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Figure 5-10 shows a trace of an incorrect remote switch WWN using a Special Frame
Figure 5-10 Trace of Incorrect Remote Switch WWN Using a Special Frame
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
On Solaris systems, a successful login is found in the /var/adm/messages directory, and should look
similar to the following example:
Mar 14 12:53:23 ca-sun1 iscsid[12745]: [ID 702911 daemon.notice] discovery process for
172.22.91.223 finished, exiting
Mar 14 12:58:45 ca-sun1 iscsid[12802]: [ID 448557 daemon.notice] logged into
DiscoveryAddress 172.22.91.223:3260 isid 023d0040
Mar 14 12:58:45 ca-sun1 iscsid[12802]: [ID 702911 daemon.notice] iSCSI target 2 =
iqn.com.domainname.vrrp-11.gw.21000020375aff77 at0
Mar 14 12:58:45 ca-sun1 iscsid[12809]: [ID 529321 daemon.notice] logged into target
iqn.com.domainname.vrrp-11.gw.21000020375aff77 7
Mar 14 12:58:45 ca-sun1 iscsid[12802]: [ID 702911 daemon.notice] iSCSI target 3 =
iqn.com.domainname.vrrp-11.gw.21000020374baf02 at0
Mar 14 12:58:45 ca-sun1 iscsid[12810]: [ID 529321 daemon.notice] logged into target
iqn.com.domainname.vrrp-11.gw.21000020374baf02 7
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Figure 5-12 shows a failed iSCSI login for the Windows 2000 driver.
On Solaris systems, a failed login is found in the /var/adm/messages directory and should look similar
to the following example.
Mar 14 11:44:42 ca-sun1 iscsid[12561]: [ID 702911 daemon.notice] login rejected: initiator
error (01)
Mar 14 11:44:42 ca-sun1 iscsid[12561]: [ID 702911 daemon.error] Hard discovery login
failure to 172.22.91.223:3260 - exiting
Mar 14 11:44:42 ca-sun1 iscsid[12561]: [ID 702911 daemon.notice] discovery process for
172.22.91.223 finished, exiting
Configuring Authentication
Whenever you experience a login failure, use the show authentication command to see if the iSCSI
authentication is correctly defined. A sample of local authentication should look like this:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
telnet/ssh:not enabled
iscsi:enabled <<<<<<<<<<<<<<<<<<<
authentication method:local
console:enabled
telnet/ssh:enabled
iscsi:enabled
switch#
username:iscsiuser
secret:1234567812345678
Adjust the radius timeout and retransmission accordingly, as they have default value of 1 sec and 1 time.
Figure 5-13 shows a Windows-based Radius server configuration.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If the items shown above match, verify that the client username and password match those in the Radius
database.
The following example shows the results of the debug security radius comand, if the iSCSI client logs
in successfully.
switch#
switch# Mar 4 23:16:20 securityd: received CHAP authentication request for user002
Mar 4 23:16:20 securityd: RADIUS is enabled, hence it will be tried first for CHAP
authentication
Mar 4 23:16:20 securityd: reading RADIUS configuration
Mar 4 23:16:20 securityd: opening radius configuration for group:default
Mar 4 23:16:20 securityd: opened the configuration successfully
Mar 4 23:16:20 securityd: GET request for RADIUS global config
Mar 4 23:16:20 securityd: got back the return value of global radius configuration
operation:success
Mar 4 23:16:20 securityd: closing RADIUS pss configuration
Mar 4 23:16:20 securityd: opening radius configuration for group:default
Mar 4 23:16:20 securityd: opened the configuration successfully
Mar 4 23:16:20 securityd: GETNEXT request for radius index:0 addr:
Mar 4 23:16:20 securityd: got some reply from 171.71.49.197
Mar 4 23:16:20 securityd: verified the response from:171.71.49.197
Mar 4 23:16:20 securityd: RADIUS server sent accept for authentication request for
user002
Mar 4 23:16:25 securityd: received CHAP authentication request for user002
Mar 4 23:16:25 securityd: RADIUS is enabled, hence it will be tried first for CHAP
authentication
Mar 4 23:16:25 securityd: reading RADIUS configuration
Mar 4 23:16:25 securityd: opening radius configuration for group:default
Mar 4 23:16:25 securityd: opened the configuration successfully
Mar 4 23:16:25 securityd: GET request for RADIUS global config
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Mar 4 23:16:25 securityd: got back the return value of global radius configuration
operation:success
Mar 4 23:16:25 securityd: closing RADIUS pss configuration
Mar 4 23:16:25 securityd: opening radius configuration for group:default
Mar 4 23:16:25 securityd: opened the configuration successfully
Mar 4 23:16:25 securityd: GETNEXT request for radius index:0 addr:
Mar 4 23:16:25 securityd: got some reply from 171.71.49.197
Mar 4 23:16:25 securityd: verified the response from:171.71.49.197
Mar 4 23:16:25 securityd: RADIUS server sent accept for authentication request for
user002
Mar 4 23:16:25 securityd: got some reply from 171.71.49.197
Mar 4 23:16:25 securityd: verified the response from:171.71.49.197
Mar 4 23:16:25 securityd: RADIUS server sent accept for authentication request for
user002
The example above shows that the iSCSI client has been authenticated 3 times, first for the switch login,
and the second and third times for the SCSI drive login. The switch sends Radius attributes 1, 3, 4, 5,
6, 60 and 61 to the Radius server. The Radius server only needs to respond with request accept or
request reject.
The following example shows a radius authentication.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
.
.
interface iscsi 3/1
no shutdown
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
VSAN 1:
-----------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
-----------------------------------------------------------------------
0x750000 N 20:23:00:a0:b8:0b:14:da (SymBios) scsi-fcp:target
0x750102 N 10:00:00:00:c9:30:ba:06 (Emulex) scsi-fcp:init
0x750105 N 20:0d:00:0b:be:77:72:42 scsi-fcp:init isc..w
0x750201 N 50:08:05:f3:00:04:96:71 scsi-fcp
0x750301 N 50:08:05:f3:00:04:96:79 scsi-fcp
0x750400 N 20:00:00:02:3d:07:05:c0 (NuSpeed) scsi-fcp:init
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
iSCSI Stats:
Login: attempt: 16726, succeed: 114, fail: 16606, authen fail: 0
Rcvd: NOP-Out: 36164, Sent: NOP-In: 36160
NOP-In: 0, Sent: NOP-Out: 0
TMF-REQ: 28, Sent: TMF-RESP: 0
Text-REQ: 39, Sent: Text-RESP: 0
SNACK: 0
Unrecognized Opcode: 0, Bad header digest: 0
Command in window but not next: 0, exceed wait queue limit: 0
Received PDU in wrong phase: 0
FCP Stats:
Total: Sent: 4110679
Received: 1281518 (Error: 0, Unknown: 0)
Sent: PLOGI: 66367, Rcvd: PLOGI_ACC: 71, PLOGI_RJT: 66296
PRLI: 71, Rcvd: PRLI_ACC: 71, PRLI_RJT: 0, Error resp: 0
LOGO: 0, Rcvd: LOGO_ACC: 0, LOGO_RJT: 0
ABTS: 87, Rcvd: ABTS_ACC: 0
TMF REQ: 0
Self orig command: 213, Rcvd: data: 142, resp: 213
Rcvd: PLOGI: 614, Sent: PLOGI_ACC: 490
LOGO: 197, Sent: LOGO_ACC: 111
PRLI: 0, Sent: PRLI_ACC: 0
ABTS: 183
iSCSI Drop:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Buffer Stats:
Buffer less than header size: 48475, Partial: 2524437, Split: 3550971
Pullup give new buf: 48475, Out of contiguous buf: 0, Unaligned m_data: 0
VSAN 5:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x610002 N 20:0b:00:0b:be:77:72:42 scsi-fcp:init isc..w
0x6101e1 NL 22:00:00:20:37:c5:2d:6d (Seagate) scsi-fcp:target
0x6101e2 NL 22:00:00:20:37:c5:2e:2e (Seagate) scsi-fcp:target
0x6101e4 NL 22:00:00:20:37:c5:23:56 (Seagate) scsi-fcp:target
0x6101e8 NL 22:00:00:20:37:c5:26:0a (Seagate) scsi-fcp:target
Target node:
Statistics:
PDU: Command: 0, Response: 0
Bytes: TX: 0, RX: 0
Number of connection: 1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
TCP parameters
Connection Local 10.1.29.100:3260, Remote 10.1.29.101:1026
Path MTU 1500 bytes
Current retransmission timeout is 310 ms
Round trip time: Smoothed 179 ms, Variance: 33
Advertized window: Current: 62 KB, Maximum: 62 KB, Scale: 0
Peer receive window: Current: 63 KB, Maximum: 63 KB, Scale: 0
Congestion window: Current: 63 KB
VSAN ID 5, FCID 0x610002
No. of FC sessions: 4
No. of iSCSI sessions: 4
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
The default MTU size of an ethernet network is 1500, while the FC networks generally support
maximum frame sizes of 2148 bytes.. This means that an iSCSI gateway will need to chop the FC frames
into two TCP segments or IP fragments while transferring form the FC side to the IP side depending on
how this chopping is implemented within the device.
The IPS module adjusts the Receive Data Field Size that it advertises to its FC partner, according to the
MTU that is configured on the corresponding Gigagbit port of an iSCSI client.
If left to default MTU, the FC frame size from the Target device is decreased to match the maximum
Ethernet frame size, so that the switching of the packet through the switch is swifter. Hence, one point
of performance tuning is increasing the MTU of the IP network between the peers. In this setup there is
one single Catalyst switch.
Jumbo support was enabled for the IPS ports, as well as the MTU for the VLAN corresponding to these
ports was increased.
The second point is to increase the TCP window size of the iSCSI end points. Depending on the latency
between the iSCSI client and IPS, this will need fine tuning. The switch’s iSCSI configuration defines
the TCP window size in kilobytes.
Any value starting with 64K ( > 65535 = 0xFFFF bytes) will automatically trigger TCP window scaling
according to RFC1323. The IPS TCP Window scaling begins only when the remote peer (iSCSI client
in this case) requests it. This means that you need to configure the TCP stack of your client to trigger
this functionality (see Figure 5-14).
For the FC side, depending on the direction of the traffic, the B2Bcredit of the ports corresponding to
the input interfaces (feeding/receiving traffic to/from the iSCSI side) could be increased, especially in
the case of local Gigabit Ethernet attached iSCSI clients.
Each of the above-mentioned commands are taken from a scenario in Figure 5-14. The important
sections of the displays are highlighted/italicized or bolded.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS 9216_Top
1.1(0.133c)
2/1 FC 1/3
Shark-nas
10.48.69.233 Catalyst 6000
C4
FC
FC
E-ISL ESS 2105/F20
HBA
MDS 9216_Bottom
94230
1.1(0.133c)
Lab Setup
This is the lab setup that was used in collecting the performance-related information.
The server was an IBM PentiumIII Server: Dual CPU @ 1.13 Ghz
The tcp window-size at both ends was set to 1MB (1024K).
The IBM ESS Shark had a hardcoded B2B value of 64 (not configurable).
The fcrxbbcredit on the corresponding switch port (fc1/3) was set to the same value.
The C4 and C8 represented the corresponding port WWPNs for the IBM Shark storage subsytem. See
below for full WWPN:
C4 Î 50:05:07:63:00:c4:94:4c (in VSAN 778)
C8 Î 50:05:07:63:00:c8:94:4c (in VSAN 777)
interface GigabitEthernet2/1
ip address 10.48.69.251 255.255.255.192
iscsi authentication none
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
no shutdown
vrrp 1
priority 110
address 10.48.69.250
(This is the iSCSI target IP address for the Windows iSCSI client.)
no shutdown
interface iscsi2/1
tcp pmtu-enable
tcp window-size 1024
(To increase the receive window size of the IPS module (in kilobytes).)
tcp sack-enable
no shutdown
To verify the connectivity between your client and the IPS iSCSI service:
VSAN 777:
--------------------------------------------------------------------------
FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE
--------------------------------------------------------------------------
0x610000 N 50:05:07:63:00:c8:94:4c (IBM) scsi-fcp:target fc..
0x610001 N 20:05:00:0c:30:6c:24:42 scsi-fcp:init isc..w
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
MDS_BOTTOM#
MDS_BOTTOM# show interface iscsi 2/1
iscsi2/1 is up
Hardware is GigabitEthernet
Port WWN is 20:41:00:0c:30:57:5e:c0
Admin port mode is ISCSI
Port mode is ISCSI
Speed is 1 Gbps
Number of iSCSI session: 2, Number of TCP connection: 2
Configured TCP parameters
Local Port is 3260
PMTU discover is enabled (default)
(This is especially required if there may be devices without jumbo support in the path. The initial TCP
3-way handshake will establish a session with a high MSS value (provided both the IPS module and the
iSCSI client are configured/capable) even if there are devices without jumbo frame support in the path.
Without PMTU discovery, this will create problems.)
Keepalive-timeout 60
Initial-retransmit-time 300
(If there is high delay between the peers, this is one of the parameters that can be adjusted. There’s no
real formula, rather use trial and error to find the optimum value for your network. Try lower values as
well as higher ones, and get hints from the show ips stats tcp display.)
Max-retransmissions 8
Window-size 1024000
Sack is enabled
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Target node:
Statistics:
PDU: Command: 0, Response: 0
Bytes: TX: 0, RX: 0
Number of connection: 1
TCP parameters
Local 10.48.69.250:3260, Remote 10.48.69.233:1026
Path MTU: 1500 bytes
Retransmission timeout: 300 ms
Round trip time: Smoothed 150 ms, Variance: 31
Advertized window: Current: 998 KB, Maximum: 1000 KB, Scale: 4
Peer receive window: Current: 1000 KB, Maximum: 1000 KB, Scale: 4
Congestion window: Current: 12 KB
VSAN ID 777, FCID 0x610001
No. of FC sessions: 1
No. of iSCSI sessions: 1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
(This is the window size set on the IPS iscsi interface. See Figure 5-15.)
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
pWWN: 50:05:07:63:00:c8:94:4c
Verify that the local port, rather than a remote that is reached via an ISL link
is used for the storage target by the above field to avoid suboptimal access to storage.
You can see that C8 is the locally attached port of the shark storage subsystem.
nWWN: 50:05:07:63:00:c8:94:4c
Session state: LOGGED_IN
1 iSCSI sessions share this FC session
Target: shark_nas
Negotiated parameters
RcvDataFieldSize 2048 our_RcvDataFieldSize 1392
MaxBurstSize 0, EMPD: FALSE
Random Relative Offset: FALSE, Sequence-in-order: Yes
Statistics:
PDU: Command: 0, Response: 1612007
MDS_BOTTOM#
Thefollowing example shows the effect of changing the Gigabit MTU on FC RcvDataFieldSize.
interface GigabitEthernet2/1
ip address 10.48.69.249 255.255.255.192
iscsi authentication none
switchport mtu 2440
no shutdown
vrrp 1
address 10.48.69.250
no shutdown
Target node:
Statistics:
PDU: Command: 0, Response: 0
Bytes: TX: 0, RX: 0
Number of connection: 1
TCP parameters
Local 10.48.69.250:3260, Remote 10.48.69.233:1026
Path MTU: 2440 bytes
Retransmission timeout: 420 ms
Round trip time: Smoothed 94 ms, Variance: 83
Advertized window: Current: 999 KB, Maximum: 1000 KB, Scale: 4
Peer receive window: Current: 1024 KB, Maximum: 1024 KB, Scale: 4
Congestion window: Current: 11 KB
VSAN ID 777, FCID 0x700003
No. of FC sessions: 1
No. of iSCSI sessions: 1
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Statistics:
PDU: Command: 11, Response: 11
Bytes: TX: 2152, RX: 0
Number of connection: 1
TCP parameters
Local 10.48.69.250:3260, Remote 10.48.69.233:1040
Path MTU: 2440 bytes
Retransmission timeout: 370 ms
Round trip time: Smoothed 47 ms, Variance: 81
Advertized window: Current: 999 KB, Maximum: 1000 KB, Scale: 4
Peer receive window: Current: 1024 KB, Maximum: 1024 KB, Scale: 4
Congestion window: Current: 12 KB
To get the real benefit of this increased MTU and higher FC Frame Size, the path between the iSCSI
client and the IPS iSCSI interface (as well as the host NIC) has to be capable of supporting this high
MTU.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
If you do not have access to the host, one way to see if the host is also configured for high MTU/MSS
(as well as the path in the middle) is to check the split packets field in the show ips stats tcp display :
However this is a generic display for all TCP sessions. That is, if you have some Hosts with high
MTU-capable NICs, and some others without, it may be difficult to assess which is which.
MDS_Top# show ips stats tcp interface gig 2/1 detail (truncated output)
TCP Statistics for port GigabitEthernet2/1
TCP send stats
10 segments, 240 bytes
5 data, 5 ack only packets
0 control (SYN/FIN/RST), 0 probes, 0 window updates
0 segments retransmitted, 0 bytes
0 retransmitted while on ethernet send queue, 0 packets split
………
MDS_Top#
Afterward, traffic starts flowing from the FC storage towards the server that is connected via iSCSI to
the IPS.
MDS_Top# show ips stats tcp interface gig 2/1 detail (truncated output)
TCP Statistics for port GigabitEthernet2/1
TCP send stats
715535 segments, 943511612 bytes
712704 data, 2831 ack only packets
0 control (SYN/FIN/RST), 0 probes, 0 window updates
0 segments retransmitted, 0 bytes
0 retransmitted while on ethernet send queue, 345477 packets split
………
C H A P T E R 6
Troubleshooting the Fabric
There are several things you can do to use Fabric Manager to troubleshoot your fabric.
This chapter contains the following topics:
• Analyzing Switch Device Health, page 6-55
• Analyzing End-to-End Connectivity, page 6-56
• Analyzing Switch Fabric Configuration, page 6-56
• Analyzing the Results of Merging Zones, page 6-57
• Issuing the Show Tech Support Command, page 6-58
• Using Traceroute and Other Troubleshooting Tools, page 6-59
• Locating Other Switches, page 6-59
• Configuring an OUI, page 6-60
Step 1 Click Switch Health... from the Fabric Manager Tools menu.
The Switch Health Analysis window is displayed.
Step 2 Click Start to identify any problems that may currently be affecting the selected switch.
The Switch Health Analysis window displays any problems affecting the selected switches.
Step 3 Click Clear to remove the contents of the Switch Health Analysis window.
Step 4 Click Close to close the window.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 1 Choose End to End Connectivity... from the Fabric Manager tools menu.
The End to End Connectivity Analysis dialog is displayed.
Step 2 Select the VSAN in which you want to verify connectivity from the VSAN dropdown list.
Step 3 Identify any latency issues in the network fabric by clicking the option Report average latencies greater
than and entering the number of microseconds.
Step 4 Click Ensure that members can communicate to perform a Fibre Channel ping between the selected end
points.
Step 5 Identify the number of packets, the size of each packet, and the timeout in milliseconds.
Step 6 Analyze the redundant paths between endpoints by clicking Ensure that redundant paths exist between
members.
Step 7 Click Analyze.
The End to End Connectivity Analysis window displays the selected end points with the switch to which
each is attached, and the source and target ports used to connect it.
The output shows all the requests which have failed. The possible descriptions are:
• Ignoring empty zone—No requests are issued for this zone.
• Ignoring zone with single member—No requests are issued for this zone.
• Source/Target are unknown—No nameserver entries exist for the ports or we have not discovered
the port during discovery.
• Both devices are on the same switch.
• No paths exist between the two devices.
• VSAN does not have an active zone set and the default zone is denied.
• Average time ... micro secs—The latency value was more than the threshold supplied.
Step 8 Click Clear to remove the contents of the window.
Step 9 Click Close to close the window.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 1 Click Fabric Configuration... from the Fabric Manager Tools menu.
The Fabric Configuration Analysis dialog is displayed.
Step 2 Choose if you want to compare the selected switch to another switch or to a Policy File.
• If you are making a switch comparison, click Policy Switch and then click the drop-down arrow to
see a list of switches.
• If you are making a policy comparison, click Policy File. Then the button to the right of this option
to browse your file system and select a policy file (*.XML).
Step 3 Click Rules... to set the rules to apply when running the Fabric Configuration Analysis tool.
The Rules window is displayed.
Step 4 Change the default rules as required and click OK.
Step 5 Click Compare.
The system analyzes the configuration and displays issues that arise as a result of the comparison.
Step 6 Click to place a checkmark in the Resolve column for the issues you want to resolve.
Step 7 Resolve them by selecting the Resolve Issues option.
Step 8 Click Clear to remove the contents of the window.
Step 9 Click Close to close the window.
Step 1 Choose Merge Analysis... from the Fabric Manager Zone menu.
The Zone Merge Analysis dialog is displayed.
Step 2 Select a switch from each pull-down list.
Step 3 Select the VSAN for which you want to perform the zone merge analysis.
Step 4 Click Analyze.
The Zone Merge Analysis window displays any inconsistencies between the zone configuration of the
two selected switches.
Step 5 Click Clear to remove the contents of the window.
Step 6 Click Close to close the window.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note If you would like to view the Show Tech Support files without using Fabric Manager, you can
open them with any text editor. Each file is named with the switch’s IP address and has a .TXT
extension (for example, 111.22.33.444.txt).
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Step 1 Choose Locate Devices by Subnet from the Fabric Manager File menu.
You see the Locate Switches dialog box.
Step 2 Enter a range of specific addresses belonging to a specific subnet which limit the research for the
switches. To look for a Cisco MDS 9000 switch belonging to subnet 192.168.199.0, use the following
string:
192.168.100.[1-254]
Multiple ranges can be specified, separated by commas. For example, to look for all the devices in the
two subnets 192.168.199.0 and 192.169.100.0, use the following string:
192.168.100.[1-254], 192.169.100.[1-254]
Step 3 Enter the appropriate read community string in the Read Community field.
The default value for this string is “public.”
Step 4 Click Display Cisco MDS 9000 Only to display only the Cisco MDS 9000 Family switches in your
network fabric.
Step 5 Click Search to discover switches and devices in your network fabric. You see the results of the discovery
in the Locate Switches window.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Note The number in the lower left corner of the screen increments as the device locator attempts to
discover the devices in your network fabric. When the discovery process is complete, the number
indicates the number of rows displayed.
Configuring an OUI
When two WWNs in different VSANs on the same fabric have the same IP address, you will need to
specify an Organizationally Unique Identifier (OUI) that Fabric Manager can use to differentiate the
WWNs. If Fabric Manager encounters this situation, a dialog is displayed. Enter the OUI in the
appropriate fields in the dialog. Restart Fabric Manager for your changes to take effect.
Note This situation does not affect the availability or the functionality of the switch and/or fabric.
C H A P T E R 7
Troubleshooting Fabric Manager Issues
This chapter contains some common issues you may experience while using Cisco Fabric Manager, and
provides solutions.
This chapter contains the following topics:
• Can I Set the Map Layout So It Stays After I Restart Fabric Manager?, page 7-61
• Two Switches Show on my Map, But I Only Have One Switch, page 7-62
• There is a Red Line Through the Switch. What’s Wrong?, page 7-62
• There is a Dotted Orange Line Through the Switch. What’s Wrong?, page 7-62
• Can I Upgrade Without Losing My Map Settings?, page 7-62
• Are There Any Restrictions When Using Fabric Manager Across FCIP?, page 7-62
• Running Cisco Fabric Manager with Multiple Interfaces, page 7-63
• Configuring a Proxy Server, page 7-64
• Clearing Topology Maps, page 7-64
• Can I Use Fabric Manager in a Mixed Software Environment?, page 7-65
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
To specify an interface for Fabric Manager Server, perform the following steps:
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
To specify an interface for the Fabric Manager Client or Device Manager, perform the following steps:
Step 1 Double-click the Java Web Start application manager icon on your Windows desktop, or Chose Program
Files > Java Web Start.
Step 2 Select File > Preferences from the Java WebStart Application Manager.
Step 3 Click the Manual radio button and enter the IP address of the proxy server in the HTTP Proxy field.
Step 4 Enter the HTTP port number used by your proxy service in the HTTP Port field.
Step 5 Click OK.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
Caution Any devices not currently accessible (may be offline) will be purged.
Se n d c o m m e n t s t o m d s f e e d b a ck - d o c @ c i s c o . c o m .
INDEX
C T
verifying
fabric configuration 1-11
E
zone configuration 1-12
end-to-end connectivity
See connectivity
Z
zones
F
merging 1-12
fabric configuration, analyzing 1-11
launching
CLI 1-12