Table of Contents

Product Overview

Configuration Fundamentals

Configuring the Switch

Managing Licenses

Using the Command-Line Interface

LAN Switching

Configuring VLANs

Configuring Private VLANs

Configuring Rapid PVST+

Configuring Multiple Spanning Tree

Configuring STP Extensions

Configuring Port Channels

Configuring Access and Trunk Interfaces

Configuring the MAC Address Table

Configuring IGMP Snooping

Configuring Traffic Storm Control

Configuring Ethernet Interfaces

Switch Security Features

Configuring RADIUS

Configuring TACACS+

Configuring SSH and Telnet

Configuring ACLs

Configuring AAA

System Management

Configuring User Accounts and RBAC

Configuring Session Manager

Configuring Online Diagnostics

Configuring System Message Logging

Configuring Call Home

Configuring SNMP

Configuring RMON

Using Cisco Fabric Services

Fibre Channel over Ethernet

Configuring Virtual Interfaces

Configuring FCoE

Quality of Service

Configuring QoS

SAN Switching

Configuring Domain Parameters

Configuring N-Port Virtualization

Configuring VSAN Trunking

Configuring SAN PortChannels

Configuring and Managing VSANs

Configuring and Managing Zones

Distributing Device Alias Services

Configuring Fibre Channel Routing Services and Protocols

Managing FLOGI, Name Server, FDMI, and RSCN Databases

Discovering SCSI Targets

Advanced Features and Concepts

Configuring FC-SP and DHCHAP

Configuring Port Security

Configuring Fabric Binding

Configuring Fabric Configuration Servers

Configuring Port Tracking

Configuring Fibre Channel Interfaces

Troubleshooting

Troubleshooting

Configuration Limits

Configuring SPAN

Preface

Product Overview

The Cisco Nexus 5000 Series is a family of top-of-rack switches for the data center. The Cisco Nexus 5000 Series offers high-speed Ethernet switching and supports Fibre Channel over Ethernet (FCoE) to provide data center I/O consolidation (IOC).

The Nexus 5010 switch provides 20 fixed Ethernet ports in a 1 RU switch and the Nexus 5020 switch provides 40 fixed Ethernet ports in a 2 RU switch. Optional expansion modules provide native Fibre Channel ports and additional Ethernet ports.

This chapter describes the Cisco Nexus 5000 Series switches and includes the following sections:

- New Technologies in the Cisco Nexus 5000 Series

- Cisco Nexus 5000 Series Switch Hardware

- Cisco Nexus 5000 Series Switch Software

- Typical Deployment Topologies

- Supported Standards

New Technologies in the Cisco Nexus 5000 Series

Cisco Nexus 5000 Series switches introduce several new technologies, which are described in the following sections:

- Fibre Channel over Ethernet

- I/O Consolidation

- Virtual Interfaces

Fibre Channel over Ethernet

Fibre Channel over Ethernet (FCoE) provides a method of encapsulating Fibre Channel traffic over a physical Ethernet link. FCoE frames use a unique Ethertype so that FCoE traffic and standard Ethernet traffic can be carried on the same link.

Fibre Channel traffic requires a lossless transport layer. Native Fibre Channel implements lossless service using a buffer-to-buffer credit system. For FCoE traffic, the Ethernet link must provide lossless service.

Ethernet links on Cisco Nexus 5000 Series switches provide two mechanisms to ensure lossless transport for FCoE traffic: link-level flow control and priority flow control.

IEEE 802.3x link-level flow control allows a congested receiver to signal the far end to pause the data transmission for a short period of time. The pause functionality is applied to all the traffic on the link.

The priority flow control (PFC) feature applies pause functionality to specific classes of traffic on the Ethernet link. For example, PFC can provide lossless service for the FCoE traffic, and best-effort service for the standard Ethernet traffic. PFC can provide different levels of service to specific classes of Ethernet traffic (using IEEE 802.1p traffic classes).

I/O Consolidation

I/O consolidation (IOC) allows a single network technology to carry IP, SAN and IPC traffic.

FCoE enables an evolutionary approach to IOC. The upper Fibre Channel layers are unchanged, so the Fibre Channel operational model is maintained. FCoE network management and configuration is similar to a native Fibre Channel network.

Cisco Nexus 5000 Series switches use FCoE to carry Fibre Channel and Ethernet traffic on the same physical Ethernet connection between the switch and the server. At the server, the connection terminates to a converged network adapter (CNA) . The adapter presents two interfaces to the server’s operating system (OS): one Ethernet NIC interface and one Fibre Channel HBA interface. The server OS is not aware of the FCoE encapsulation (See Figure 1-1)

At the switch, the incoming Ethernet port separates the Ethernet and Fibre Channel traffic (using Ethertype to differentiate the frames). Ethernet frames and Fibre Channel frames are switched to their respective network-side interfaces.

Cisco Nexus 5000 Series switches provide quality of service (QoS) capabilities to ensure lossless service across the switch for Fibre Channel traffic. Best-effort service can be applied to all of the Ethernet traffic or specific classes of Ethernet traffic can be configured with different QoS levels.

Figure 1-1 I/O Consolidation

Virtual Interfaces

When FCoE is enabled, a physical Ethernet cable carries traffic for a logical Fibre Channel connection.

The Cisco Nexus 5000 Series switch uses virtual interfaces to represent the logical Fibre Channel connections. For configuration purposes, virtual Fibre Channel interfaces are implemented as Layer 2 subinterfaces of the physical Ethernet interface.

Ethernet features (such as link debounce timer and VLAN membership) are configured on the physical Ethernet interface. Logical Fibre Channel features (such as VSAN membership) are configured on the virtual Fibre Channel interfaces.

Cisco Nexus 5000 Series Switch Hardware

The Cisco Nexus 5000 Series includes the Nexus 5010 and Nexus 5020 switches. The Cisco Nexus 5000 Series switch hardware is described in the following topics:

- Chassis

- Expansion Modules

- Ethernet Interfaces

- Fibre Channel Interfaces

- Management Interfaces

Chassis

The Nexus 5010 switch is a 1 RU chassis and the Nexus 5020 switch is a 2 RU chassis designed for rack mounting. The chassis supports redundant fans and power supplies.

The Cisco Nexus 5000 Series switching fabric is low latency, nonblocking and supports Ethernet frame sizes from 64 to 9216 bytes.

Expansion Modules

The Nexus 5010 switch has one slot and the Nexus 5020 switch has two slots for optional expansion modules. The following expansion modules are available:

- N5K-M1404 provides four 10-Gigabit Ethernet ports, and four 1/2/4 Gb Fibre Channel ports.

- N5K-M1600 provides six 10-Gigabit Ethernet ports.

- N5K-M1008 provides eight 1/2/4 Gb Fibre Channel ports.

The expansion modules are field-replaceable units (FRUs) that support online insertion and removal (OIR).

Ethernet Interfaces

The Nexus 5010 switch has 20 fixed 10-Gigabit Ethernet ports equipped with SFP+ interface adapters. The first 8 ports are switchable 1-Gigabit/10-Gigabit ports. Up to 6 additional 10-Gigabit Ethernet ports are available on an expansion module.

The Nexus 5020 switch has 40 fixed 10-Gigabit Ethernet ports equipped with SFP+ interface adapters. The first 16 ports are switchable 1-Gigabit/10-Gigabit ports. Up to 12 additional 10-Gigabit Ethernet ports are available on the expansion modules.

All of the 10-Gigabit Ethernet ports support FCoE. Each port can be used as a downlink (connected to a server) or as an uplink (to the data center LAN).

Fibre Channel Interfaces

Fibre Channel ports are optional on the Cisco Nexus 5000 Series switch. When using expansion modules up to eight Fibre Channel ports are available on the Nexus 5010 switch and up to sixteen Fibre Channel ports are available on the Nexus 5020 switch.

Each Fibre Channel port can be used as a downlink (connected to a server) or as an uplink (to the data center SAN fabric).

Management Interfaces

A Cisco Nexus 5000 Series switch has two dedicated management interfaces (one serial console port and one 10/100/1000 Ethernet interface).

Cisco Nexus 5000 Series Switch Software

The Cisco Nexus 5000 Series switch is a Layer 2 device, which runs the Cisco Nexus operating system (NX-OS). The Cisco Nexus 5000 Series switch software is described in the following topics:

- Ethernet Switching

- FCoE and Fibre Channel Switching

- Licensing

- QoS

- Serviceability

- Switch Management

- Network Security Features

- Virtual Device Contexts

Ethernet Switching

Cisco Nexus 5000 Series switches are designed to support high-density, high-performance Ethernet systems and provide the following Ethernet switching features:

- IEEE 802.1D-2004 Rapid and Multiple Spanning Tree Protocols (802.1w and 802.1s)

- IEEE 802.1Q VLANs and trunks

- IEEE 802.3ad link aggregation

- Private VLANs

- Traffic suppression (unicast, multicast, and broadcast)

FCoE and Fibre Channel Switching

Cisco Nexus 5000 Series switches support data center I/O consolidation (IOC) by providing FCoE interfaces (to the servers) and native Fibre Channel interfaces (to the SAN).

FCoE and Fibre Channel switching includes the following features:

- Cisco fabric services

- N-port virtualization

- VSANs and VSAN trunking

- Zoning

- Distributed device alias service

- SAN port channels

Licensing

Cisco Nexus 5000 Series switches are shipped with the licenses installed. The switch provides commands to manage the licenses and install additional licenses.

QoS

The Cisco Nexus 5000 Series switch provides quality of service (QoS) capabilities such as traffic prioritization and bandwidth allocation on egress interfaces.

The default QoS configuration on the switch provides lossless service for Fibre Channel and FCoE traffic. QoS can be configured to provide additional classes of service for Ethernet traffic.

Serviceability

The Cisco Nexus 5000 Series switch serviceability functions provide data for network planning and help to improve problem resolution time.

This section includes the following topics:

- Switched Port Analyzer

- Ethanalyzer

- Call Home

- Online Diagnostics

Switched Port Analyzer

The switched port analyzer (SPAN) feature allows an administrator to analyze all traffic between ports by nonintrusively directing the SPAN session traffic to a SPAN destination port that has an external analyzer attached to it.

Ethanalyzer

Ethanalyzer is a Cisco NX-OS protocol analyzer tool based on the Wireshark (formerly Ethereal) open source code. Ethanalyzer is a command-line version of Wireshark for capturing and decoding packets. You can use Ethanalyzer to troubleshoot your network and analyze the control-plane traffic. For more information about Ethanalyzer, see Cisco NX-OS Troubleshooting Guide, Release 4.0.

Call Home

The Call Home feature continuously monitors hardware and software components to provide e-mail-based notification of critical system events. A versatile range of message formats is available for optimal compatibility with pager services, standard e-mail, and XML-based automated parsing applications. The feature offers alert grouping capabilities and customizable destination profiles. This feature can be used, for example, to directly page a network support engineer, send an e-mail message to a network operations center (NOC), and employ Cisco AutoNotify services to directly generate a case with the Cisco Technical Assistance Center (TAC). This feature is a step toward autonomous system operation, which enables networking devices to inform IT when a problem occurs and helps to ensure that the problem is resolved quickly.

Online Diagnostics

Cisco generic online diagnostics (GOLD) is a suite of diagnostic facilities to verify that hardware and internal data paths are operating as designed. Boot-time diagnostics, continuous monitoring, and on-demand and scheduled tests are part of the Cisco GOLD feature set. GOLD allows rapid fault isolation and continuous system monitoring.

Switch Management

This section includes the following topics:

- Simple Network Management Protocol

- Role-Based Access Control

- Configuration Methods

Simple Network Management Protocol

Cisco NX-OS is compliant with Simple Network Management Protocol (SNMP) version 1, version 2, and version 3. A full set of Management Information Bases (MIBs) is supported.

Role-Based Access Control

With role-based access control (RBAC), you can limit access to switch operations by assigning roles to users. Administrators can customize access and restrict it to the users who require it.

Configuration Methods

You can configure Cisco Nexus 5000 Series switches using direct network configuration methods or web services hosted on a Fabric Manager server.

This section includes the following topics:

- Configuring with CLI, XML Management Interface, or SNMP

- Configuring with Cisco MDS Fabric Manager

Configuring with CLI, XML Management Interface, or SNMP

You can configure Cisco Nexus 5000 Series switches using the command line interface (CLI), the XML management interface over SSH, or SNMP as follows:

- CLI —You can configure switches using the CLI from an SSH session, a Telnet session. or the console port. SSH provides a secure connection to the device.

- XML Management Interface over SSH—You can configure switches using the XML management interface, which is a programming interface based on the NETCONF protocol that complements the CLI functionality. For more information, see the Cisco NX-OS XML Management Interface User Guide, Release 4.0 .

- SNMP—SNMP allows you to configure switches using Management Information Bases (MIBs).

Configuring with Cisco MDS Fabric Manager

You can configure Cisco Nexus 5000 Series switches using the Fabric Manager client, which runs on a local PC and uses the Fabric Manager server.

Network Security Features

Cisco NX-OS Release 4.0 includes the following security features:

- Authentication, authorization, and accounting (AAA) and TACACS+

- RADIUS

- Secure Shell (SSH) Protocol Version 2

- Simple Network Management Protocol Version 3 (SNMPv3)

- MAC ACLs and IP ACLs, including port-based ACLs (PACLs) and VLAN-based ACLs (VACLs).

Virtual Device Contexts

Cisco NX-OS can segment operating system and hardware resources into virtual device contexts (VDC) that emulate virtual devices. The Cisco Nexus 5000 Series switch does not support multiple VDCs. All switch resources are managed in the default VDC.

Typical Deployment Topologies

In this release, the Cisco Nexus 5000 Series switch is typically deployed in the following topologies:

- Ethernet TOR Switch Topology

- IOC Topology

Ethernet TOR Switch Topology

The Cisco Nexus 5000 Series switch can be deployed as a 10-Gigabit Ethernet top-of-rack (TOR) switch, with uplinks to the data center LAN distribution layer switches. An example configuration in shown in Figure 1-2.

In this example, the blade server rack incorporates blade switches that support 10-Gigabit Ethernet uplinks to the Cisco Nexus 5000 Series switch. The blade switches do not support FCoE, so there is no FCoE traffic and no Fibre Channel ports on the Cisco Nexus 5000 Series switch.

In the example configuration, the Cisco Nexus 5000 Series switch has Ethernet uplinks to two Catalyst switches. If STP is enabled in the data center LAN, the links to one of the switches will be STP active and the links to the other switch will be STP blocked.

Figure 1-2 Ethernet TOR Switch Topology

The servers are connected to the data center SAN through MDS 9134 SAN switches. The server Fibre Channel ports require standard Fibre Channel HBAs.

IOC Topology

Figure 1-3 shows a typical I/O consolidation (IOC) scenario for the Cisco Nexus 5000 Series switch.

Figure 1-3 I/O Consolidation Topology

The Cisco Nexus 5000 Series switch connects to the server ports using FCoE. Ports on the server require converged network adapters. For redundancy, each server connects to both switches. Dual-port CNA adapters can be used for this purpose. The CNA is configured in active-passive mode, and the server needs to support server-based failover.

On the Cisco Nexus 5000 Series switch, the Ethernet network-facing ports are connected to two Catalyst 6500 switches. Depending on required uplink traffic volume, there may be multiple ports connected to each Catalyst 6500 switch, configured as port channels. If STP is enabled in the data center LAN, the links to one of the switches will be STP active and the links to the other switch will be STP blocked.

The SAN network-facing ports on the Cisco Nexus 5000 Series switch are connected to Cisco MDS 9000 Family switches. Depending on required traffic volume, there may be multiple Fibre Channel ports connected to each MDS 9000 Family switch, configured as SAN port channels.

Supported Standards

Table 1-1 lists the standards supported by the Cisco Nexus 5000 Series switches.

Table 1-1 IEEE Compliance

Standard

Description

802.1D

MAC Bridges

802.1s

Multiple Spanning Tree Protocol

802.1w

Rapid Spanning Tree Protocol

802.3ad

Link aggregation with LACP

802.3ae

10 Gigabit Ethernet

802.1Q

VLAN Tagging

802.1p

Using the Command-Line Interface

This chapter describes the command-line interface (CLI) and CLI command modes. It includes the following sections:

- Accessing the Command Line Interface

- Using the CLI

- Using Commands

- Using CLI Variables

- Using Command Aliases

- Defining Command Aliases

- Command Scripts

Accessing the Command Line Interface

You can connect to the switch using a terminal plugged into the console port. See Console Settings for information on how to set console port parameters.

You can also connect to the switch with Telnet or SSH. The switch supports up to eight simultaneous Telnet and SSH connections. To connect with Telnet or SSH, you need to know the hostname or IP address of the switch.

To make a Telnet connection to the switch, perform these steps:

Command

Purpose

Step 1

telnet {hostname | ip_addr}

Makes a Telnet connection from your host to the switch that you want to access.

Step 2

Login: admin

Password: password

Initiates authentication.
.

Step 3

switch# exit

Exits the session when finished.

Alternatively, to make an SSH connection to the switch, use the following command:

Command

Purpose

ssh {hostname | ip_addr}

Makes an SSH connection from your host to the switch that you want to access.

Using the CLI

The section includes the following topics:

- Using CLI Command Modes

- CLI Command Hierarchy

- EXEC Mode Commands

- Configuration Mode Commands

Using CLI Command Modes

Switches in the Cisco Nexus 5000 Series have two main command modes: user EXEC mode and configuration mode. The commands available to you depend on the mode you are in. To obtain a list of available commands in either mode, type a question mark (?) at the system prompt.

Table 1-1 lists and describes the two commonly used modes, how to enter the modes, and the resulting system prompts. The system prompt helps you identify which mode you are in and the commands that are available to you in that mode.

Table 1-1 Frequently Used Switch Command Modes

Mode

Description

How to Access

Prompt

EXEC

Enables you to temporarily change terminal settings, perform basic tests, and display system information.

Note Changes made in this mode are generally not saved across system resets.

At the switch prompt, enter the required EXEC mode command.

switch#

Configuration mode

Enables you to configure features that affect the system as a whole.

Note Changes made in this mode are saved across system resets if you save your configuration.

From EXEC mode, enter the configure terminal command.

switch(config)#

You can abbreviate commands and keywords by entering just enough characters to make the command unique from other commands. For example, you can abbreviate the configure terminal command to conf t.

Changing Command Modes

Configuration mode, also known as terminal configuration mode, has several submodes. Each of these submodes places you further down in the prompt hierarchy. When you type exit, the switch backs out of the current level and returns you to the previous level. When you type end, the switch backs out to the user EXEC level. You can also press Ctrl-Z in configuration mode as an alternative to typing end.

Listing the Commands Used with Each Command Mode

You can display the commands available in any command mode by typing a question mark (?) at the switch prompt.

CLI Command Hierarchy

CLI commands are organized hierarchically, with commands that perform similar functions grouped under the same level. For example, all commands that display information about the system, configuration, or hardware are grouped under the show command, and all commands that allow you to configure the switch are grouped under the configure terminal command.

To execute a command, you enter the command by starting at the top level of the hierarchy. For example, to configure an interface, use the config terminal command. Once you are in configuration mode, enter the interface command. When you are in the interface submode, you can query the available commands.

The following example shows how to query the available command in the interface submode:

switch# configure terminal

switch(config)# interface fc 3/1

switch(config-if)# ?

channel-group add to/remove from a san-port-channel

description Enter description of maximum 80 characters

exit Exit from command interpreter

fcdomain Configure fcdomain parameters

fspf Configure FSPF parameters

no Negate a command or set its defaults

out-of-service Put an interface out of service.

shutdown Enable/disable an interface

switchport Configure switchport parameters

EXEC Mode Commands

When you start a session on the switch, you begin in EXEC mode. From EXEC mode, you can enter configuration mode. Most of the EXEC commands are one-time commands, such as show commands, which display the current configuration status.

The following commands are available in EXEC mode:

switch# ?

callhome callhome commands

cd Change current directory

clear Reset functions

cli CLI commands

clock Manage the system clock

configure Enter configuration mode

copy Copy from one file to another

debug Debugging functions

debug-filter Enable filtering for debugging functions

delete delete a file

dir list files in a directory

discover discover information

end Exit configuration mode

ethanalyzer Configure cisco fabric analyzer

exit Exit from command interpreter

fcping Ping an N-Port

fctrace Trace the route for an N-Port.

file File management commands

find Find a file below the current directory

format Format disks

gunzip Uncompresses LZ77 coded files

gzip Compresses file using LZ77 coding

install upgrade software

ip Configure IP features

license Enter the license configuration mode

logit Add syslog message

mkdir Create new directory

move Move files

no Negate a command or set its defaults

ntp Execute NTP commands

ping Test network reachability

purge Deletes unused data

pwd View current directory

reload Reboot the entire box

replace Discard the entire configuration and load the entire configuration in

<filename>

rmdir delete a directory

run-script Run shell scripts

san-port-channel Port-Channel related commands

send Send message to open sessions

session Configure session preferences

setup Run the basic SETUP command facility

show Show running system information

sleep Sleep for the specified number of seconds

ssh SSH to another system

syslog Execute a logging command

system System management commands

tac-pac save tac information to a specific location

tail Display the last part of a file

telnet Telnet to another system

terminal Set terminal line parameters

terminate Terminates a config session

test test command

traceroute Traceroute to destination

undebug Disable Debugging functions (See also debug)

unmount unmount compact flash disk or usb drive

update Update license

write Write current configuration

xml xml agent

zone Execute Zone Server commands

zoneset Execute zoneset commands

Configuration Mode Commands

Configuration mode allows you to make changes to the existing configuration. When you save the configuration, these commands are saved across switch reboots. Once you are in configuration mode, you can enter interface configuration mode, zone configuration mode, and a variety of protocol-specific modes. Configuration mode is the starting point for all configuration commands.

The following commands are available in configuration mode:

switch# configure terminal

switch(config)# ?

aaa Configure aaa functions

arp ARP

banner Configure banner message

boot Configure boot variables

callhome Enter the callhome configuration mode

cdp CDP Configuration parameters

cfs CFS configuration commands

class-map Configure class-map

cli Configure CLI aliases

clock Configure time-of-day clock

device-alias Device-alias configuration commands

diagnostic Diagnostic commands

end Exit configuration mode

exit Exit from command interpreter

fabric Switch fabric information

fabric-binding Fabric Binding configuration

fc FCoE/FC feature

fcalias Fcalias configuration commands

fcdomain Enter the fcdomain configuration mode

fcdroplatency configure switch or network latency

fcflow Configure fcfloww

fcid-allocation Add/remove company id(or OUIs) from auto area list

fcinterop Interop commands

fcns name server configuration

fcroute Configure FC routes

fcs Configure Fabric Config Server

fcsp Config commands for FC-SP

fctimer configure fibre channel timers

fdmi config commands for FDMI

feature Command to enable/disable features

fspf Configure fspf

hostname Configure system's host name

hw-module Enable/Disable OBFL information

in-order-guarantee set in-order delivery guarantee

interface Configure interfaces

ip Configure IP features

ipv6 Configure IPv6 features

line Configure a terminal line

lldp Configure global LLDP parameters

logging Modify message logging facilities

mac MAC configuration commands

mac-address-table MAC Address Table

monitor Ethernet SPAN

no Negate a command or set its defaults

npiv Nx port Id Virtualization (NPIV) feature enable

npv Config commands for FC N_port Virtualizer

ntp NTP Configuration

pm packet manager

policy-map Configure policy-map

port-channel Add to/remove from a port-channel

port-security Configure Port Security

port-track Configure Switch port track config

privilege Command privilege parameters

prompt Define default prompt

radius-server Configure RADIUS related parameters

resequence Resequence a list with sequence numbers

rib Configure RIB parameters

rlir config commands for RLIR

rmon Remote Monitoring

role Configure roles

rscn config commands for RSCN

scsi-target scsi-target configuration

show Show running system information

snmp-server Configure snmp server

spanning-tree Spanning Tree Subsystem

ssh Configure SSH parameters

svi svi configuration commands

switchname Configure system's host name

system system config command

system Configure system

tacacs+ Enable tacacs+

telnet Enable telnet

track Object tracking configuration commands

trunk Configure Switch wide trunk protocol

username Configure user information.

vlan Vlan commands

vrf Configure VRF parameters

vsan Enter the vsan configuration mode

wwn Set secondary base MAC addr and range for additional WWNs

xml xml agent

zone Zone configuration commands

zoneset Zoneset configuration commands

Using Commands

You can configure the CLI to function in two ways: configure it interactively by entering commands at the CLI prompt or create an ASCII file containing switch configuration information (use the CLI to edit and activate the file).

Listing Commands and Syntax

In any command mode, you can obtain a list of available commands by entering a question mark (?).

switch# ?

To see a list of commands that begin with a particular character sequence, type those characters followed by a question mark (?). Do not include a space before the question mark.

switch# co?

configure copy

To list keywords or arguments, enter a question mark in place of a keyword or argument. Include a space before the question mark. This form of help is called command syntax help because it reminds you which keywords or arguments are applicable based on the commands, keywords, and arguments you have already entered.

switch# # configure ?

<CR>

terminal Configure the system from terminal input

Tip If you are having trouble entering a command, check the system prompt and enter the question mark (?) for a list of available commands. You might be in the wrong command mode or using incorrect syntax.

Entering Command Sequences

Undoing or Reverting to Default Values or Conditions

You can enter the no form of any command to perform the following actions:

- Undo an incorrectly entered command.

If you enter the zone member command, you can undo the results:

switch(config)# zone name test vsan 1

switch(config-zone)# member pwwn 12:12:12:12:12:12:12:12

switch(config-zone)# no member pwwn 12:12:12:12:12:12:12:12

WARNING: Zone is empty. Deleting zone test. Exit the submode.

switch(config-zone)#

- Delete a created facility.

- Revert to the default value.

If you enter the zone merge-control restrict vsan command, you can undo the results:

switch(config)# zone merge-control restrict vsan 10

switch(config)# no zone merge-control restrict vsan 10

switch(config)#

Using Keyboard Shortcuts

You can execute an EXEC mode command from a configuration mode or submode prompt. You can enter this command from any submode within the configuration mode. When in configuration mode (or in any submode), enter the do command along with the required EXEC mode command. The command is executed at the EXEC level, and the prompt resumes its current mode level.

switch(config)# do terminal session-timeout 0

switch(config)#

In this example, terminal session-timeout is an EXEC mode command. You are entering an EXEC mode command using the configuration mode do command.

The do command applies to all EXEC mode commands other than the end and exit commands. You can also use the help (?) and command completion (Tab) features for EXEC commands when entering a do command along with the EXEC command.

Table 1-2 lists some useful command keys that can be used in both EXEC and configuration modes.

Table 1-2 Useful Command Keys

Command

Description

Ctrl-P

Up history

Ctrl-N

Down history

Ctrl-X-H

List history

Alt-P

History search backwards
completes a previously entered command.

Alt-N

History search forwards

Ctrl-G

Exit

Ctrl-Z

End

Ctrl-L

Clear session

Table 1-3 Common Configuration Submodes

Submode Name

From Configuration Mode, Enter:

Submode Prompt

Call home

callhome

switch(config-callhome)#

FCS Registration

fcs register

switch(config-fcs-register)#

From FCS registration submode:

platform name name vsan vsan-id

switch(config-fcs-register-attrib)#

Fibre Channel alias

fcalias name name vsan vsan-id

switch(congif-fcalias)#

FSPF

fspf config vsan vsan-id

switch(config-(fspf-config))#

Interface configuration

interface type slot/port

switch(config-if)#

Line console

line console

switch(config-console)

Virtual terminal line

line vty

switch(config-line)#

Role

role name

switch(config-role)#

VLAN

vlan

switch(config-vlan)#

VSAN database

vsan database

switch(config-vsan-db)#

Zone

zone name string vsan vsan-id

switch(config-zone)#

Zone set

zoneset name name vsan vsan-id

switch(config-zoneset)#

Using CLI Variables

The Cisco Nexus 5000 Series CLI parser supports the definition and use of variables in CLI commands. CLI variables can be used as follows:

- Entered directly on the command line.

- Passed to the child script initiated using the run-script command.

The variables defined in the parent shell are available for use in the child run-script command process (see the “Executing Commands Specified in a Script” section).

- Passed as command line arguments to the run-script command (see the “Executing Commands Specified in a Script” section).

CLI variables have the following characteristics:

- You cannot reference a variable through another variable using nested references.

- You can define persistent variables that are available across switch reloads.

- You can reference only one predefined system variable, which is the TIMESTAMP variable.

User-Defined Persistent CLI Variables

You can define CLI session variables to persist only for the duration of your CLI session using the cli var name command in EXEC mode. CLI session variables are useful for scripts that you execute periodically.

switch# show interface $(testinterface)

fc2/1 is up

Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)

Port WWN is 20:01:00:0d:ec:0e:1d:00

Admin port mode is auto, trunk mode is on

snmp traps are enabled

Port mode is F, FCID is 0x01000b

Port vsan is 1

Speed is 2 Gbps

Transmit B2B Credit is 7

Receive B2B Credit is 16

Receive data field Size is 2112

Beacon is turned off

5 minutes input rate 256 bits/sec, 32 bytes/sec, 1 frames/sec

5 minutes output rate 256 bits/sec, 32 bytes/sec, 1 frames/sec

232692 frames input, 7447280 bytes

0 discards, 0 errors

0 CRC, 0 unknown class

0 too long, 0 too short

232691 frames output, 7448692 bytes

0 discards, 0 errors

0 input OLS, 0 LRR, 0 NOS, 0 loop inits

1 output OLS, 1 LRR, 0 NOS, 1 loop inits

16 receive B2B credit remaining

7 transmit B2B credit remaining

Use the show cli variables command to display user-defined CLI session variables. The following example displays user-defined CLI session variables:

switch# show cli variables

VSH Variable List

-----------------

TIMESTAMP="2005-10-24-21.29.33"

testinterface="fc 1/1"

Use the cli no var name command to remove user-defined CLI session variables. The following example removes a user-defined CLI session variable:

switch# cli no var name testinterface

Using Command Aliases

Command alias support has the following characteristics:

- Command aliases are global for all user sessions.

- Command aliases are saved across reboots.

- Commands being aliased must be typed in full without abbreviation.

- Command alias translation always takes precedence over any keyword in any configuration mode or submode.

- Command alias support is only available on the supervisor module, not the switching modules.

- Command alias configuration takes effect for other user sessions immediately.

- You cannot override the default command alias alias , which aliases the show cli alias command.

- Nesting of command aliases is permitted to a maximum depth of 1. One command alias can refer to another command alias that must refer to a valid command, not to another command alias.

- A command alias always replaces the first command keyword on the command line.

- You can define command aliases for commands in any configuration submode or the EXEC mode.

Defining Command Aliases

You can define command aliases using the cli alias name command in configuration mode.

The following example shows how to display the command aliases defined on the switch:

switch# alias

CLI alias commands

==================

alias :show cli alias

gigint :interface gigabitethernet

shintbr :show interface brief

shfcintup :shintbr | include up | include fc

Command Scripts

This section includes the following topics:

- Executing Commands Specified in a Script

- Using CLI Variables in Scripts

- Setting the Delay Time

Executing Commands Specified in a Script

The run-script command executes the commands specified in a file. To use this command, be sure to create the file and specify commands in the required order.

Note You cannot create the script file at the switch prompt. You can create the script file on an external machine and copy it to the bootflash: directory. This section assumes that the script file resides in the bootflash: directory.

The syntax for this command is run-script filename.

This example displays the CLI commands specified in a test file that resides in the bootflash: directory.

switch# show file bootflash:testfile

configure terminal

interface fc 3/1

no shutdown

end

show interface fc 3/1

This file output is in response to the run-script command executing the contents in the test file:

switch# run-script bootflash:testfile

'configure terminal'

Enter configuration commands, one per line. End with CNTL/Z.

'interface fc 3/1'

'no shutdown'

'end'

'show interface fc 3/1'

fc3/1 is trunking

Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)

Port WWN is 20:81:00:0d:ec:6b:cd:c0

Peer port WWN is 20:01:00:0d:ec:0d:d0:00

Admin port mode is auto, trunk mode is on

snmp link state traps are enabled

Port mode is TE

Port vsan is 1

Speed is 2 Gbps

Transmit B2B Credit is 255

Receive B2B Credit is 16

Receive data field Size is 2112

Beacon is turned off

Trunk vsans (admin allowed and active) (1)

Trunk vsans (up) (1)

Trunk vsans (isolated) ()

Trunk vsans (initializing) ()

5 minutes input rate 96 bits/sec, 12 bytes/sec, 0 frames/sec

5 minutes output rate 64 bits/sec, 8 bytes/sec, 0 frames/sec

77423 frames input, 6708868 bytes

0 discards, 0 errors

0 CRC, 0 unknown class

0 too long, 0 too short

77302 frames output, 4184976 bytes

0 discards, 0 errors

1 input OLS, 2 LRR, 0 NOS, 0 loop inits

1 output OLS, 0 LRR, 1 NOS, 0 loop inits

16 receive B2B credit remaining

255 transmit B2B credit remaining

Using CLI Variables in Scripts

You can use CLI variables defined by the cli var command (see the “Using CLI Variables” section) or passed as arguments in the run-script command.

The following example shows how to use CLI session variables in a script file used by the run-script command:

switch# cli var name testinterface fc 1/1

switch# show file bootflash:test1.vsh

show interface $(testvar)

switch# run-script bootflash:test1.vsh

`show interface $(testvar)`

fc2/1 is down (SFP not present)

Hardware is Fibre Channel

Port WWN is 20:01:00:05:30:00:8e:1e

Admin port mode is auto, trunk mode is on

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

1 frames input, 128 bytes

0 discards, 0 errors

0 CRC, 0 unknown class

0 too long, 0 too short

1 frames output, 128 bytes

0 discards, 0 errors

0 input OLS, 0 LRR, 0 NOS, 0 loop inits

0 output OLS, 0 LRR, 0 NOS, 0 loop inits

0 receive B2B credit remaining

0 transmit B2B credit remaining

The following example shows how you can pass CLI session variable as arguments to a child run-script command process:

switch# show file bootflash:test1.vsh

show interface $(var1) $(var2)

switch# run bootflash:test2.vsh var1="fc2/1" var2="brief"

`show interface $(var1) $(var2)`

-------------------------------------------------------------------------------

Interface Vsan Admin Admin Status SFP Oper Oper Port

Mode Trunk Mode Speed Channel

Mode (Gbps)

-------------------------------------------------------------------------------

fc2/1 1 auto on sfpAbsent -- -- -- \

Setting the Delay Time

The sleep command delays an action by a specified number of seconds.

The syntax for this command is sleep seconds.

switch# sleep 30

You will see the switch prompt return after 30 seconds. This command is useful within scripts. For example, if you create a command script called test-script.

switch# show file bootflash:test-script

discover scsi-target remote

sleep 10

show scsi-target disk

switch# run-script bootflash:test-script

When you execute the test-script command script, the switch software executes the discover scsi-target remote command, and then waits for 10 seconds before executing the show scsi-target disk command.

Configuring Ethernet Interfaces

This section describes the configuration of the Ethernet interfaces on a Cisco Nexus 5000 Series switch. It includes the following sections:

- Information About Ethernet Interfaces

- Configuring Ethernet Interfaces

- Displaying Interface Information

Information About Ethernet Interfaces

The Ethernet ports can operate as standard Ethernet interfaces connected to servers or to a LAN.

The Ethernet interfaces also support Fibre Channel over Ethernet (FCoE). FCoE allows the physical Ethernet link to carry both Ethernet and Fibre Channel traffic. For additional information, see Chapter 1, “Configuring FCoE” and Chapter1, “Configuring Virtual Interfaces”

On a Cisco Nexus 5000 Series switch, the Ethernet interfaces are enabled by default.

This section includes the following topics:

- About the Interface Command

- Unidirectional Link Detection Parameter

- Interface Speed

- About the Debounce Timer Parameters

- About MTU Configuration

About the Interface Command

You can enable the various capabilities of the Ethernet interfaces on a per-interface basis using the interface command. When you enter the interface command, you specify the following information:

- Interface type—All physical Ethernet interfaces use the ethernet keyword.

- Slot number

– Slot 1 includes all the fixed ports.

– Slot 2 includes the ports on the upper expansion module (if populated).

– Slot 3 includes the ports on the lower expansion module (if populated),

- Port number

– Port number within the group.

Unidirectional Link Detection Parameter

This section includes the following topics:

- UDLD Overview

- Default UDLD Configuration

- UDLD Aggressive and Nonaggressive Modes

UDLD Overview

The Cisco-proprietary Unidirectional Link Detection (UDLD) protocol allows ports that are connected through fiber-optic or copper (for example, Category 5 cabling) Ethernet cables to monitor the physical configuration of the cables and detect when a unidirectional link exists. When the switch detects a unidirectional link, UDLD shuts down the affected LAN port and alerts the user. Unidirectional links can cause a variety of problems, including spanning tree topology loops.

UDLD is a Layer 2 protocol that works with the Layer 1 protocols to determine the physical status of a link. At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected LAN ports. When you enable both autonegotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

A unidirectional link occurs whenever traffic transmitted by the local device over a link is received by the neighbor but traffic transmitted from the neighbor is not received by the local device. If one of the fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up. In this case, the logical link is undetermined, and UDLD does not take any action. If both fibers are working normally at Layer 1, then UDLD at Layer 2 determines whether those fibers are connected correctly and whether traffic is flowing bidirectionally between the correct neighbors. This check cannot be performed by autonegotiation, because autonegotiation operates at Layer 1.

A Cisco Nexus 5000 Series switch periodically transmits UDLD frames to neighbor devices on LAN ports with UDLD enabled. If the frames are echoed back within a specific time frame and they lack a specific acknowledgment (echo), the link is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify and disable unidirectional links.

Note By default, UDLD is locally disabled on copper LAN ports to avoid sending unnecessary control traffic on this type of media.

Figure 1-1 shows an example of a unidirectional link condition. Device B successfully receives traffic from device A on the port. However, device A does not receive traffic from device B on the same port. UDLD detects the problem and disables the port.

Figure 1-1 Unidirectional Link

Default UDLD Configuration

Table 1-1 UDLD Default Configuration

Feature

Default Value

UDLD global enable state

Globally disabled

UDLD aggressive mode

Disabled

UDLD per-port enable state for fiber-optic media

Enabled on all Ethernet fiber-optic LAN ports

UDLD per-port enable state for twisted-pair (copper) media

Disabled on all Ethernet 10/100 and 1000BASE-TX LAN ports

For information on configuring the UDLD for the device and its port, see the “Configuring the UDLD Mode” section.

UDLD Aggressive and Nonaggressive Modes

UDLD aggressive mode is disabled by default. You can configure UDLD aggressive mode only on point-to-point links between network devices that support UDLD aggressive mode. If UDLD aggressive mode is enabled, when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD frame, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port is disabled.

To prevent spanning tree loops, nonaggressive UDLD with the default interval of 15 seconds is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).

When you enable the UDLD aggressive mode, the following occurs:

- One side of a link has a port stuck (both transmission and receive)

- One side of a link remains up while the other side of the link is down

In these cases, the UDLD aggressive mode disables one of the ports on the link, which prevents traffic from being discarded.

Interface Speed

A Cisco Nexus 5000 Series switch has a number of fixed 10-Gigabit ports, each equipped with SFP+ interface adapters. The Nexus 5010 switch has 20 fixed ports, the first eight of which are switchable 1-Gigabit/10-Gigabit ports. The Nexus 5020 switch has 40 fixed ports, the first 16 of which are switchable 1-Gigabit/10-Gigabit ports.

About the Debounce Timer Parameters

The port debounce time is the amount of time that an interface waits to notify the supervisor of a link going down. During this time, the interface waits to see if the link comes back up. The wait period is a time when traffic is stopped.

You can enable the debounce timer for each interface and specify the delay time in milliseconds.

Caution When you enable the port debounce timer the link up and link down detections are delayed, resulting in a loss of traffic during the debounce period. This situation might affect the convergence and reconvergence of some protocols.

About MTU Configuration

A per-physical Ethernet interface maximum transmission unit (MTU) is not supported. Instead, MTU is set according to the QoS classes. You modify MTU by setting Policy and Class maps. See Chapter 1, “Configuring QoS” for more details.

When you show the interface settings, an MTU of 1500 is displayed for physical Ethernet interfaces and a receive data field size of 2112 is displayed for Fibre Channel interfaces.

Configuring Ethernet Interfaces

This section shows how to configure Ethernet interfaces. It includes the following topics:

- Configuring the UDLD Mode

- Configuring Interface Speed

- Configuring the CDP Parameter

- Configuring the Debounce Timer

- Configuring the Description Parameter

- Disabling and Restarting Ethernet Interfaces

Configuring the UDLD Mode

You can configure normal or aggressive unidirectional link detection (UDLD) modes for Ethernet interfaces on devices configured to run UDLD. Before you can enable a UDLD mode for an interface, you must make sure that UDLD is already enabled on the device that includes the interface. UDLD must also be enabled on the other linked interface and its device.

To use the normal UDLD mode, you must configure one of the ports for normal mode and configure the other port for the normal or aggressive mode. To use the aggressive UDLD mode, you must configure both ports for the aggressive mode.

Note Before you begin UDLD must be enabled for the other linked port and its device.

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# feature udld

switch(config)# no feature udld

Disables UDLD for the device.

Step 3

switch(config)# show udld global

Displays the UDLD status for the device.

Step 4

switch(config)# interface ethernet slot/port

Specifies an interface to configure, and enters interface configuration mode.

Step 5

switch(config-if)# udld {enable | disable | aggressive}

Enables the normal UDLD mode, disables UDLD, or enables the aggressive UDLD mode.

Step 6

switch(config-if)# show udld interface

Displays the UDLD status for the interface.

This example shows how to enable the UDLD for the switch:

switch# configure terminal

switch(config)# feature udld

This example shows how to enable the normal UDLD mode for an Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# udld enable

This example shows how to enable the aggressive UDLD mode for an Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# udld aggressive

This example shows how to disable UDLD for an Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# udld disable

This example shows how to disable UDLD for the switch:

switch# configure terminal

switch(config)# no feature udld

Configuring Interface Speed

The first eight ports of a Nexus 5010 switch and the first 16 ports of a Nexus 5020 switch are switchable 1-Gigabit/10-Gigabit ports. The default interface speed is 10-Gigabit. To configure these ports for 1-Gigabit Ethernet, insert a 1-Gigabit Ethernet SFP transceiver into the applicable port then set its speed with the speed command.

To configure a 1-Gigabit Ethernet port, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

Enters interface configuration mode for the specified interface. This interface must have a 1-Gigabit Ethernet SFP+ transceiver inserted into it.

Step 3

switch(config-if)# speed speed

Sets the speed on the interface.

The following example shows how to set the speed for a 1-Gigabit Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# speed 1000

This command can only be applied to a physical Ethernet interface.

Note If the interface and transceiver speed is mismatched, this shows as "SFP validation failed" when you run the show interface ethernet slot/port command. For example, if you insert 1-Gigabit SFP transceiver into a port without configuring speed 1000 you will get this error. By default, all ports are 10-Gigabit.

Configuring the CDP Parameter

You can enable or disable the Cisco Discovery Protocol (CDP) for Ethernet interfaces. This protocol works only when you have it enabled on both interfaces on the same link.

To enable or disable CDP for an interface, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

Enters interface configuration mode for the specified interface.

Step 3

switch(config-if)# cdp enable

Enables CDP for the interface.

To work correctly, this parameter must be enabled for both interfaces on the same link.

switch(config-if)# cdp enable

Disables CDP for the interface.

The following example shows how to enable CDP for an Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# cdp enable

This command can only be applied to a physical Ethernet interface.

Configuring the Debounce Timer

You can enable the debounce timer for Ethernet ports by specifying a debounce time (in milliseconds) or disable the timer by specifying a debounce time of 0.

You can show the debounce times for all of the Ethernet ports by using the show interface debounce command.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

Enters interface configuration mode for the specified interface.

Step 3

switch(config-if)# link debounce time milliseconds

Enables the debounce timer for the amount of time (1 to 5000 milliseconds) specified.

Disables the debounce timer if you specify 0 milliseconds.

This example shows how to enable the debounce timer and set the debounce time to 1000 milliseconds for an Ethernet interface:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# link debounce time 1000

This example shows how to disable the debounce timer for an Ethernet interface:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# link debounce time 0

This command can only be applied to a physical Ethernet interface.

Configuring the Description Parameter

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Enters interface configuration mode for the specified interface.

Step 3

switch(config-if)# description test

Specifies the description for the interface.

This example shows how to set the interface description to “Server 3 Interface”.

switch# configure terminal

switch(config)# interface ethernet 1/3

switch(config-if)# description Server 3 Interface

Disabling and Restarting Ethernet Interfaces

You can shut down and restart an Ethernet interface. This action disables all of the interface functions and marks the interface as being down on all monitoring displays. This information is communicated to other network servers through all dynamic routing protocols. When shut down, the interface is not included in any routing updates.

To disable an interface, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

Enters interface configuration mode for the specified interface.

Step 3

switch(config-if)# shutdown

Disables the interface.

The following example shows how to disable an Ethernet port:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# shutdown

To restart an interface, perform this task:

Command

Purpose

switch(config-if)# no shutdown

Restarts the interface.

The following example shows how to restart an Ethernet interface:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# no shutdown

Displaying Interface Information

Command

Purpose

switch# show interface type slot/port

Displays the detailed configuration of the specified interface.

switch# show interface type slot/port capabilities

Displays detailed information about the capabilities of the specified interface. This option is only available for physical interfaces

switch# show interface type slot/port transceiver

Displays detailed information about the transceiver connected to the specified interface. This option is only available for physical interfaces.

switch# show interface brief

Displays the status of all interfaces.

switch# show interface debounce

Displays the debounce status of all interfaces.

switch# show interface flowcontrol

Displays the detailed listing of the flow control settings on all interfaces.

The show interface command is invoked from EXEC mode and displays the interface configurations. Without any arguments, this command displays the information for all the configured interfaces in the switch.

The following example shows how to display the physical Ethernet interface:

switch# show interface ethernet 1/4

Ethernet1/1 is up

Hardware is 1000/10000 Ethernet, address is 000d.eca3.5f08 (bia 000d.eca3.5f08)

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,

reliability 255/255, txload 190/255, rxload 192/255

Encapsulation ARPA

Port mode is trunk

full-duplex, 10 Gb/s, media type is 1/10g

Input flow-control is off, output flow-control is off

Auto-mdix is turned on

Rate mode is dedicated

Switchport monitor is off

Last clearing of "show interface" counters never

5 minute input rate 942201806 bytes/sec, 14721892 packets/sec

5 minute output rate 935840313 bytes/sec, 14622492 packets/sec

Rx

129141483840 input packets 0 unicast packets 129141483847 multicast packets

0 broadcast packets 0 jumbo packets 0 storm suppression packets

8265054965824 bytes

0 No buffer 0 runt 0 Overrun

0 crc 0 Ignored 0 Bad etype drop

0 Bad proto drop

Tx

119038487241 output packets 119038487245 multicast packets

0 broadcast packets 0 jumbo packets

7618463256471 bytes

0 output CRC 0 ecc

0 underrun 0 if down drop 0 output error 0 collision 0 deferred

0 late collision 0 lost carrier 0 no carrier

0 babble

0 Rx pause 8031547972 Tx pause 0 reset

The following example shows how to display the physical Ethernet capabilities:

switch# show interface ethernet 1/3 capabilities

Ethernet1/1

Model: AGD11342302

Type: 10Gbase-SR

Speed: 1000,10000

Duplex: full

Trunk encap. type: 802.1Q

Channel: no

Broadcast suppression: percentage(0-100)

Flowcontrol: rx-(off/on),tx-(off/on)

Rate mode: none

QOS scheduling: rx-(6q1t),tx-(1p6q0t)

CoS rewrite: no

ToS rewrite: no

SPAN: yes

UDLD: yes

Link Debounce: yes

Link Debounce Time: yes

MDIX: no

The following example shows how to display the physical Ethernet transceiver:

switch# show interface ethernet 1/3 transceiver

Ethernet1/3

sfp is present

name is CISCO-AVAGO

part number is SFBR-7700SDZ B4 R

revision is B4 R

serial number is AGD1134229V 070823

nominal bitrate is 0 MBits/sec

Link length supported for 50/125mm fiber is 0 m(s)

Link length supported for 62.5/125mm fiber is 0 m(s)

cisco id is --

cisco extended id number is 4

The following example shows how to display a brief interface status (some of the output has been removed for brevity):

switch# show interface brief

--------------------------------------------------------------------------------

Ethernet VLAN Type Mode Status Reason Speed Port

Interface Ch #

--------------------------------------------------------------------------------

Eth1/1 200 eth trunk up none 10G(D) --

Eth1/2 1 eth trunk up none 10G(D) --

Eth1/3 300 eth access down SFP not inserted 10G(D) --

Eth1/4 300 eth access down SFP not inserted 10G(D) --

Eth1/5 300 eth access down Link not connected 1000(D) --

Eth1/6 20 eth access down Link not connected 10G(D) --

Eth1/7 300 eth access down SFP not inserted 10G(D) --

...

The following example shows how to display the link debounce status (some of the output has been removed for brevity):

switch# show interface debounce

--------------------------------------------------------------------------------

Port Debounce time Value(ms)

--------------------------------------------------------------------------------

...

Eth1/1 enable 100

Eth1/2 enable 100

Eth1/3 enable 100

...

The following example shows how to display the CDP neighbors:

switch# show cdp neighbors

Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge

S - Switch, H - Host, I - IGMP, r - Repeater,

V - VoIP-Phone, D - Remotely-Managed-Device,

s - Supports-STP-Dispute

Device ID Local Intrfce Hldtme Capability Platform Port ID

d5-switch-9.qa. Eth1/40 148 R S I WS-C6506-E Ten4/2

dist-row-d mgmt0 147 R S I WS-C3560G-48T Gig0/34

Default Physical Ethernet Settings

Parameter

Default Setting

Debounce

Enable, 100 milliseconds

Duplex

Auto (full-duplex)

Encapsulation

ARPA

MTU1

1500 bytes

Port Mode

Access

Speed

Auto (10000)

1.MTU cannot be changed per-physical Ethernet interface. You modify MTU by selecting maps of QoS classes. See “Configuring QoS,” for additional information.

Configuring AAA

This chapter describes how to configure authentication, authorization, and accounting (AAA) on Cisco Nexus 5000 Series switches.

This chapter includes the following sections:

- Information About AAA

- Prerequisites for Remote AAA

- AAA Guidelines and Limitations

- Configuring AAA

- Displaying and Clearing the Local AAA Accounting Log

- Verifying AAA Configuration

- Example AAA Configuration

- Default Settings

Information About AAA

This section includes the following topics:

- AAA Security Services

- Benefits of Using AAA

- Remote AAA Services

- AAA Server Groups

- AAA Service Configuration Options

- Authentication and Authorization Process for User Login

AAA Security Services

The AAA feature allows you to verify the identity of, grant access to, and track the actions of users managing Nexus 5000 Series switches. The Nexus 5000 Series switches support Remote Access Dial-In User Service (RADIUS) or Terminal Access Controller Access Control device Plus (TACACS+) protocols.

Based on the user ID and password combination that you provide, the Nexus 5000 Series switches perform local authentication or authorization using the local database or remote authentication or authorization using one or more AAA servers. A preshared secret key provides security for communication between the Nexus 5000 switch and AAA servers. You can configure a common secret key for all AAA servers or for only a specific AAA server.

AAA security provides the following services:

- Authentication—Identifies users, including login and password dialog, challenge and response, messaging support, and, encryption depending on the security protocol that you select.

Authentication is the process of verifying the identity of the person or device accessing the Nexus 5000 Series switches. This process is based on the user ID and password combination provided by the entity trying to access the Nexus 5000 switch. The Nexus 5000 Series switches allow you to perform local authentication (using the local lookup database) or remote authentication (using one or more RADIUS or TACACS+ servers).

- Authorization—Provides access control.

AAA authorization is the process of assembling a set of attributes that describe what the user is authorized to perform. Authorization in Nexus 5000 Series switches is provided by attributes that are downloaded from AAA servers. Remote security servers, such as RADIUS and TACACS+, authorize users for specific rights by associating attribute-value (AV) pairs, which define those rights with the appropriate user.

- Accounting—Provides the method for collecting information, logging the information locally, and sending the information to the AAA server for billing, auditing, and reporting.

The accounting feature tracks and maintains a log of every management session used to access the Nexus 5000 Series switches. You can use this information to generate reports for troubleshooting and auditing purposes. You can store accounting logs locally or send them to remote AAA servers.

The accounting log feature does not log the show commands. For example, the feature does not log the show version or show module commands.

Note The Cisco NX-OS software supports authentication, authorization, and accounting independently. For example, you can configure authentication and authorization without configuring accounting.

Benefits of Using AAA

AAA provides the following benefits:

- Increased flexibility and control of access configuration

- Scalability

- Standardized authentication methods, such as RADIUS and TACACS+

- Multiple backup devices

Remote AAA Services

Remote AAA services provided through RADIUS and TACACS+ protocols have the following advantages over local AAA services:

- User password lists for each Nexus 5000 Series switch in the fabric are easier to manage.

- AAA servers are already deployed widely across enterprises and can be easily used for AAA services.

- The accounting log for all switches in the fabric can be centrally managed.

- User attributes for each switch in the fabric than using the local databases on the switches are easier to manage.

AAA Server Groups

You can specify remote AAA servers for authentication, authorization, and accounting using server groups. A server group is a set of remote AAA servers that implement the same AAA protocol. The purpose of a server group is to provide for failover servers in case a remote AAA server fails to respond. If the first remote server in the group fails to respond, the next remote server in the group is tried until one of the servers sends a response. If all the AAA servers in the server group fail to respond, then that server group option is considered a failure. If required, you can specify multiple server groups. If a Nexus 5000 Series switch encounters errors from the servers in the first group, it tries the servers in the next server group.

AAA Service Configuration Options

On Nexus 5000 Series switches, you can have separate AAA configurations for the following services:

- User Telnet or Secure Shell (SSH) login authentication

- Console login authentication

- User management session accounting

Table 1-1 lists the CLI commands for each AAA service configuration option.

.

Table 1-1 AAA Service Configuration Commands

AAA Service Configuration Option

Related Command

Telnet or SSH login

aaa authentication login default

Console login

aaa authentication login console

User session accounting

aaa accounting default

You can specify the following authentication methods for the AAA services:

- RADIUS server groups—Uses the global pool of RADIUS servers for authentication.

- Specified server groups—Uses specified RADIUS or TACACS+ server groups for authentication.

- Local—Uses the local username or password database for authentication.

- None—Uses only the user name.

Note If the method is for all RADIUS servers, instead of a specific server group, the Nexus 5000 Series switches choose the RADIUS server from the global pool of configured RADIUS servers in the order of configuration. Servers from this global pool are the servers that can be selectively configured in a RADIUS server group on the Nexus 5000 Series switches.

Table 1-2 AAA Authentication Methods for AAA Services

AAA Service

AAA Methods

Console login authentication

Server groups, local, and none

User login authentication

Server groups, local, and none

User management session accounting

Server groups and local

Note For console login authentication, user login authentication, and user management session accounting, the Nexus 5000 Series switches try each option in the order specified. The local option is the default method when other configured options fail.

Authentication and Authorization Process for User Login

Figure 1-1 shows a flowchart of the authentication and authorization process for user login. The following process occurs:

1. When you log in to the required Nexus 5000 Series switch, you can use the Telnet, SSH, Fabric Manager or Device Manager, or console login options.

2. When you have configured the AAA server groups using the server group authentication method, the Nexus 5000 Series switch sends an authentication request to the first AAA server in the group as follows:

a. If the AAA server fails to respond, then the next AAA server is tried and so on until the remote server responds to the authentication request.

b. If all AAA servers in the server group fail to respond, then the servers in the next server group are tried.

c. If all configured methods fail, then the local database is used for authentication.

3. If the Nexus 5000 Series switches successfully authenticate you through a remote AAA server, then the following possibilities apply:

a. If the AAA server protocol is RADIUS, then user roles specified in the cisco-av-pair attribute are downloaded with an authentication response.

b. If the AAA server protocol is TACACS+, then another request is sent to the same server to get the user roles specified as custom attributes for the shell.

4. If your username and password are successfully authenticated locally, the Nexus 5000 Series switch logs you in and assigns you the roles configured in the local database.

Figure 1-1 Authorization and Authentication Flow for User Login

Note “No more server groups left” means that there is no response from any server in all server groups.

“No more servers left” means that there is no response from any server within this server group.

Prerequisites for Remote AAA

Remote AAA servers have the following prerequisites:

- At least one RADIUS or TACACS+ server must be IP reachable (see the “Configuring RADIUS Server Hosts” section and the “Configuring TACACS+ Server Hosts” section)

- The Nexus 5000 Series switch is configured as a client of the AAA servers.

- The preshared secret key is configured on the Nexus 5000 Series switch and on the remote AAA servers.

- The remote server responds to AAA requests from the Nexus 5000 Series switch (see the “Manually Monitoring RADIUS Servers or Groups” section and the “Manually Monitoring TACACS+ Servers or Groups” section).

AAA Guidelines and Limitations

The Nexus 5000 Series switches do not support all numeric usernames, whether created with TACACS+ or RADIUS, or created locally, and do not create local users with all numeric names. If an all numeric username exists on an AAA server and is entered during login, the Nexus 5000 Series switch will log in the user.

Configuring AAA

To configure AAA authentication and accounting, perform this task:

Step 1 If you want to use remote RADIUS or TACACS+ servers for authentication, configure the hosts on your Nexus 5000 Series switch. See Chapter 1, “Configuring RADIUS” and Chapter1, “Configuring TACACS+”

Step 2 Configure console login authentication methods. See the “Configuring Console Login Authentication Methods” section.

Step 3 Configure default login authentication methods for user logins. See the “Configuring Default Login Authentication Methods” section

Step 4 Configure default AAA accounting default methods. See the “Configuring AAA Accounting Default Methods” section.

The following topics describe the AAA configuration procedure in more details:

- Configuring Console Login Authentication Methods

- Configuring Default Login Authentication Methods

- Enabling Login Authentication Failure Messages

- Enabling MSCHAP Authentication

- Configuring AAA Accounting Default Methods

- Using AAA Server VSAs with Nexus 5000 Series Switches

Note If you are familiar with the Cisco IOS CLI, be aware that the Nexus 5000 Series commands for this feature might differ from the Cisco IOS commands that you would use.

Configuring Console Login Authentication Methods

This section describes how to configure the authentication methods for the console login.

The authentication methods include the following:

- Global pool of RADIUS servers

- Named subset of RADIUS or TACACS+ servers

- Local database on the Nexus 5000 Series switch

- Username only ( none )

The default method is local.

Note The group radius and group server-name forms of the aaa authentication command are used for a set of previously defined RADIUS servers. Use the radius server-host command to configure the host servers. Use the aaa group server radius command to create a named group of servers.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa authentication login console {group group-list [none]| local | none}

Configures login authentication methods for the console.

The group-list argument consists of a space-delimited list of group names. The group names are the following:

- radius —Uses the global pool of RADIUS servers for authentication.

- named-group —Uses a named subset of TACACS+ or RADIUS servers for authentication.

The local method uses the local database for authentication. The none method uses the username only.

The default console login method is local, which is used when no methods are configured or when all of the configured methods fail to respond.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show aaa authentication

(Optional) Displays the configuration of the console login authentication methods.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure authentication methods for the console login:

switch# configure terminal

switch(config)# aaa authentication login console group radius

switch(config)# exit

switch# show aaa authentication

switch# copy running-config startup-config

Configuring Default Login Authentication Methods

The authentication methods include the following:

- Global pool of RADIUS servers

- Named subset of RADIUS or TACACS+ servers

- Local database on the Nexus 5000 Series switch

- Username only

The default method is local.

Before you configure default login authentication methods, configure RADIUS or TACACS+ server groups as needed. To configure default login authentication methods, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa authentication login default {group group-list [none]| local | none}

Configures the default authentication methods.

The group-list argument consists of a space-delimited list of group names. The group names are the following:

- radius —Uses the global pool of RADIUS servers for authentication.

- named-group —Uses a named subset of TACACS+ or RADIUS servers for authentication.

The local method uses the local database for authentication. The none method uses the username only.

The default login method is local, which is used when no methods are configured or when all of the configured methods do not respond.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show aaa authentication

(Optional) Displays the configuration of the default login authentication methods.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Enabling Login Authentication Failure Messages

When you log in, the login is processed by the local user database if the remote AAA servers do not respond. If you have enabled the displaying of login failure messages, the following message is displayed :

Remote AAA servers unreachable; local authentication done.

Remote AAA servers unreachable; local authentication failed.

To enable login authentication failure messages, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa authentication login error-enable

Enables login authentication failure messages. The default is disabled.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show aaa authentication

(Optional) Displays the login failure message configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Enabling MSCHAP Authentication

Microsoft Challenge Handshake Authentication Protocol (MSCHAP) is the Microsoft version of CHAP. You can use MSCHAP for user logins to a Nexus 5000 Series switch through a remote authentication server (RADIUS or TACACS+).

Table 1-3 MSCHAP RADIUS VSAs

Vendor-ID Number

Vendor-Type Number

VSA

Description

311

11

MSCHAP-Challenge

Contains the challenge sent by an AAA server to an MSCHAP user. It can be used in both Access-Request and Access-Challenge packets.

211

11

MSCHAP-Response

Contains the response value provided by an MSCHAP user in response to the challenge. It is only used in Access-Request packets.

To enable MSCHAP authentication, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa authentication login mschap enable

Enables MS-CHAP authentication. The default is disabled.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show aaa authentication login mschap

(Optional) Displays the MS-CHAP configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring AAA Accounting Default Methods

The Nexus 5000 Series switch supports TACACS+ and RADIUS methods for accounting. The switches report user activity to TACACS+ or RADIUS security servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server.

When you activate AAA accounting, the Nexus 5000 Series switch reports these attributes as accounting records, which are then stored in an accounting log on the security server.

You can create default method lists defining specific accounting methods, which include the following:.

- RADIUS server group—Uses the global pool of RADIUS servers for accounting.

- Specified server group—Uses a specified RADIUS or TACACS+ server group for accounting.

- Local—Uses the local username or password database for accounting.

Note If you have configured server groups and the server groups do not respond, by default the local database is used for authentication.

Before you configure AAA accounting default methods, configure RADIUS or TACACS+ server groups as needed.

To configure AAA accounting default methods, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa accounting default {group group-list | local}

Configures default accounting method. One or more server group names can be specified in a space separated list.

The group-list argument consists of a space-delimited list of group names. The group names are of the following:

- radius —Uses the global pool of RADIUS servers for accounting.

- named-group —Uses a named subset of TACACS+ or RADIUS servers for accounting.

The local method uses the local database for accounting.

The default method is local, which is used when no server groups are configured or when all the configured server group do not respond.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show aaa accounting

(Optional) Displays the configuration AAA accounting default methods.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Using AAA Server VSAs with Nexus 5000 Series Switches

You can use vendor-specific attributes (VSAs) to specify the Nexus 5000 Series user roles and SNMPv3 parameters on AAA servers.

This section includes the following topics:

- About VSAs

- VSA Format

- Specifying Nexus 5000 Series switch User Roles and SMNPv3 Parameters on AAA Servers

About VSAs

The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating VSAs between the network access server and the RADIUS server. The IETF uses attribute 26. VSAs allow vendors to support their own extended attributes that are not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. The Cisco vendor ID is 9, and the supported option is vendor type 1, which is named cisco-av-pair. The value is a string with the following format:

protocol : attribute seperator value *

The protocol is a Cisco attribute for a particular type of authorization, separator is an equal sign (=) for mandatory attributes, and an asterisk (* ) indicates optional attributes.

When you use RADIUS servers for authentication on a Nexus 5000 Series switch, the RADIUS protocol directs the RADIUS server to return user attributes, such as authorization information, along with authentication results. This authorization information is specified through VSAs.

VSA Format

The following VSA protocol options are supported by the Nexus 5000 Series switches:

- Shell— Used in access-accept packets to provide user profile information.

- Accounting—Used in accounting-request packets. If a value contains any white spaces, put it within double quotation marks.

The following attributes are supported by the Nexus 5000 Series switches:

- roles—Lists all the roles assigned to the user. The value field is a string that stores the list of group names delimited by white space.

- accountinginfo—Stores additional accounting information in addition to the attributes covered by a standard RADIUS accounting protocol. This attribute is sent only in the VSA portion of the Account-Request frames from the RADIUS client on the switch, and it can only be used with the accounting protocol-related PDUs.

Specifying Nexus 5000 Series switch User Roles and SMNPv3 Parameters on AAA Servers

You can use the VSA cisco-av-pair on AAA servers to specify user role mapping for the Nexus 5000 Series switch using this format:

shell:roles="roleA roleB …"

If you do not specify the role option in the cisco-av-pair attribute, the default user role is network-operator.

For more information on user roles, see Chapter1, “Configuring User Accounts and RBAC”

Displaying and Clearing the Local AAA Accounting Log

The Nexus 5000 Series switch maintains a local log for the AAA accounting activity. To display this log and clear it, perform this task:

Command

Purpose

Step 1

switch# show accounting log [size] [start-time year month day hh:mm:ss]

Displays the accounting log contents. By default, the command output contains up to 250,000 bytes of the accounting log. You can use the size argument to limit command output. The range is from 0 to 250000 bytes. You can also specify a start time for the log output.

Step 2

switch# clear accounting log

(Optional) Clears the accounting log contents.

Note The accounting log feature does not log the show commands, For example, the feature does not log the show version or show module commands.

Verifying AAA Configuration

Command

Purpose

show aaa accounting

Displays AAA accounting configuration.

show aaa authentication [login {error-enable | mschap}]

Displays AAA authentication information.

show aaa groups

Displays the AAA server group configuration.

show running-config aaa [all]

Displays the AAA configuration in the running configuration.

show startup-config aaa

Displays the AAA configuration in the startup configuration.

Example AAA Configuration

Table 1-4 Default AAA Parameters

Parameters

Default

Console authentication method

local

Default authentication method

local

Login authentication failure messages

Disabled

MSCHAP authentication

Disabled

Default accounting method

local

Accounting log display length

Using Cisco Fabric Services

Cisco Nexus 5000 Series switches provide Cisco Fabric Services (CFS) capability, which simplifies provisioning by automatically distributing configuration information to all switches in the network.

Switch features can use the CFS infrastructure to distribute feature data or configuration data required by the feature.

This chapter contains the following sections:

- Information About CFS

- CFS Distribution

- CFS Support for Applications

- CFS Regions

- Configuring CFS Over IP

- Displaying CFS Distribution Information

- Default Settings

Information About CFS

Some features in the Cisco Nexus 5000 Series switch require configuration synchronization with other switches in the network to function correctly. Synchronization through manual configuration at each switch in the network can be a tedious and error-prone process.

Cisco Fabric Services (CFS) provides a common infrastructure for automatic configuration synchronization in the network. It provides the transport function and a set of common services to the features. CFS has the ability to discover CFS capable switches in the network and discovering feature capabilities in all CFS capable switches.

Cisco Nexus 5000 Series switches support CFS message distribution over Fibre Channel, IPv4 or IPv6 networks. If the switch is provisioned with Fibre Channel ports, CFS over Fibre Channel is enabled by default. CFS over IP must be explicitly enabled.

CFS provides the following features:

- Peer-to-peer protocol with no client-server relationship at the CFS layer.

- CFS message distribution over Fibre Channel, IPv4 or IPv6 networks.

- Three modes of distribution.

– Coordinated distributions: Only one distribution is allowed in the network at any given time.

– Uncoordinated distributions: Multiple parallel distributions are allowed in the network except when a coordinated distribution is in progress.

– Unrestricted uncoordinated distributions: Multiple parallel distributions are allowed in the network in the presence of an existing coordinated distribution. Unrestricted uncoordinated distributions are allowed to run in parallel with all other types of distributions.

The following features are supported for CFS distribution over IP:

- One scope of distribution over an IP network:

– Physical scope: The distribution spans the entire IP network.

The following features are supported for CFS distribution over Fibre Channel SANs:

- Three scopes of distribution over SAN fabrics.

– Logical scope: The distribution occurs within the scope of a VSAN.

– Physical scope: The distribution spans the entire physical topology.

– Over a selected set of VSANs: Some features require configuration distribution over some specific VSANs. These features can specify to CFS the set of VSANs over which to restrict the distribution.

- Supports a merge protocol that facilitates the merge of feature configuration during a fabric merge event (when two independent SAN fabrics merge).

CFS Distribution

The CFS distribution functionality is independent of the lower layer transport. Cisco Nexus 5000 Series switches support CFS distribution over IP and CFS distribution over Fibre Channel. Features that use CFS are unaware of the lower layer transport.

Additional details are provided in the following sections:

- CFS Distribution Modes

- Enabling/Disabling CFS Distribution on a Switch

- Verifying CFS Distribution Status

- CFS Distribution over IP

- CFS Distribution over Fibre Channel

- CFS Distribution Scopes

- CFS Merge Support

CFS Distribution Modes

CFS supports three distribution modes to accommodate different feature requirements. Only one mode is allowed at any given time. CFS distribution modes are described in the following sections:

- Uncoordinated Distribution

- Coordinated Distribution

- Unrestricted Uncoordinated Distributions

Uncoordinated Distribution

Uncoordinated distributions are used to distribute information that is not expected to conflict with that from a peer. Parallel uncoordinated distributions are allowed for a feature.

Coordinated Distribution

Coordinated distributions allow only one feature distribution at a given time. CFS uses locks to enforce this. A coordinated distribution is not allowed to start if locks are taken for the feature anywhere in the network. A coordinated distribution consists of three stages:

1. A network lock is acquired.

2. The configuration is distributed and committed.

3. The network lock is released.

Coordinated distribution has two variants:

- CFS driven —The stages are executed by CFS in response to an feature request without intervention from the feature.

- Feature driven—The stages are under the complete control of the feature.

Coordinated distributions are used to distribute information that can be manipulated and distributed from multiple switches, for example, the port security configuration.

Unrestricted Uncoordinated Distributions

Unrestricted uncoordinated distributions allow multiple parallel distributions in the network in the presence of an existing coordinated distribution. Unrestricted uncoordinated distributions are allowed to run in parallel with all other types of distributions.

Enabling/Disabling CFS Distribution on a Switch

If the switch is provisioned with Fibre Channel ports, CFS over Fibre Channel is enabled by default. CFS over IP must be explicitly enabled.

You can globally disable CFS on a switch to isolate the features using CFS from network-wide distributions while maintaining physical connectivity. When CFS is globally disabled on a switch, CFS operations are restricted to the switch.

To globally disable or enable CFS distribution on a switch, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# no cfs distribute

Globally disables CFS distribution (CFS over Fibre Channel or IP) for all applications on the switch.

switch(config)# cfs distribute

Enables (default) CFS distribution on the switch.

Verifying CFS Distribution Status

The show cfs status command displays the status of CFS distribution on the switch.

switch# show cfs status

Distribution : Enabled

Distribution over IP : Disabled

IPv4 multicast address : 239.255.70.83

IPv6 multicast address : ff15::efff:4653

CFS Distribution over IP

CFS distribution over IP supports the following features:

- Physical distribution over an entirely IP network.

- Physical distribution over a hybrid Fibre Channel and IP network with the distribution reaching all switches that are reachable over either Fibre Channel or IP.

Note The switch attempts to distribute information over Fibre Channel first and then over the IP network if the first attempt over Fibre Channel fails. CFS does not send duplicate messages if distribution over both IP and Fibre Channel is enabled.

- Distribution over IP version 4 (IPv4) or IP version 6 (IPv6).

Note CFS cannot distribute over both IPv4 and IPv6 from the same switch.

- Keepalive mechanism to detect network topology changes using a configurable multicast address.

- Compatibility with Cisco MDS 9000 Family switches running release 2.x or later.

Figure 1-1 shows a network with both Fibre Channel and IP connections. Node A forwards an event to node B over Fibre Channel. Node B forwards the event node C and node D using unicast IP. Node C forwards the event to node E using Fibre Channel.

Figure 1-1 Network Example 1 with Fibre Channel and IP Connections

Figure 1-2 is the same as Figure 1-1 except that node C and node D are connected using Fibre Channel. All processes is the same in this example because node B has node C and node D the distribution list for IP. Node C does not forward to node D because node D is already in the distribution list from node B.

Figure 1-2 Network Example 2 with Fibre Channel and IP Connections

Figure 1-3 is the same as Figure 1-2 except that node D and node E are connected using IP. Both node C and node D forward the event to E because the node E is not in the distribution list from node B.

Figure 1-3 Network Example 3 with Fibre Channel and IP Connections

CFS Distribution over Fibre Channel

For FCS distribution over Fibre Channel, the CFS protocol layer resides on top of the FC2 layer. CFS uses the FC2 transport services to send information to other switches. CFS uses a proprietary SW_ILS (0x77434653) protocol for all CFS packets. CFS packets are sent to or from the switch domain controller addresses.

CFS Distribution Scopes

Different applications on the Cisco Nexus 5000 Series switches need to distribute the configuration at various levels. The following levels are available when using CFS distribution over Fibre Channel:

- VSAN level (logical scope)

Applications that operate within the scope of a VSAN have the configuration distribution restricted to the VSAN. An example application is port security where the configuration database is applicable only within a VSAN.

Note Logical scope is not supported for FCS distribution over IP.

- Physical topology level (physical scope)

Some applications (such as NTP) need to distribute the configuration to the entire physical topology.

- Between two selected switches

Some applications operate only between selected switches in the network.

CFS Merge Support

CFS Merge is supported for CFS distribution over Fibre Channel.

An application keeps the configuration synchronized in a SAN fabric through CFS. Two such fabrics might merge as a result of an ISL coming up between them. These two fabrics could have two different sets of configuration information that need to be reconciled in the event of a merge. CFS provides notification each time an application peer comes online. If a fabric with M application peers merges with another fabric with N application peers, and if an application triggers a merge action on every notification, a link-up event results in M*N merges in the fabric.

CFS supports a protocol that reduces the number of merges required to one by handling the complexity of the merge at the CFS layer. This protocol runs per application per scope. The protocol involves selecting one switch in a fabric as the merge manager for that fabric. The other switches do not have a role in the merge process.

During a merge, the merge manager in the two fabrics exchange their configuration databases with each other. The application on one of them merges the information, decides if the merge is successful, and informs all switches in the combined fabric of the status of the merge.

In case of a successful merge, the merged database is distributed to all switches in the combined fabric and the entire new fabric remains in a consistent state. You can recover from a merge failure by starting a distribution from any of the switches in the new fabric. This distribution restores all peers in the fabric to the same configuration database.

CFS Support for Applications

The following topics describe the CFS capabilities that support applications:

- CFS Application Requirements

- Enabling CFS for an Application

- Locking the Network

- Committing Changes

- Discarding Changes

- Saving the Configuration

- Clearing a Locked Session

CFS Application Requirements

All switches in the network must be CFS capable. Switches that are not CFS capable do not receive distributions and result in part of the network not receiving the intended distribution.

CFS has the following requirements:

- Implicit CFS usage—The first time you issue a CFS task for a CFS-enabled application, the configuration modification process begins and the application locks the network.

- Pending database—The pending database is a temporary buffer to hold uncommitted information. The uncommitted changes are not applied immediately to ensure that the database is synchronized with the database in the other switches in the network. When you commit the changes, the pending database overwrites the configuration database (also known as the active database or the effective database).

- CFS distribution enabled or disabled on a per-application basis—The default (enable or disable) for CFS distribution state differs between applications. If CFS distribution is disabled for an application, then that application does not distribute any configuration nor does it accept a distribution from other switches in the network.

- Explicit CFS commit—Most applications require an explicit commit operation to copy the changes in the temporary buffer to the application database, to distribute the new database to the network, and to release the network lock. The changes in the temporary buffer are not applied if you do not perform the commit operation.

Enabling CFS for an Application

All CFS-based applications provide an option to enable or disable the distribution capabilities.

Applications have the distribution enabled by default.

The application configuration is not distributed by CFS unless distribution is explicitly enabled for that application.

Verifying Application Registration Status

The show cfs application command displays the applications that are currently registered with CFS. The first column displays the application name. The second column indicates whether the application is enabled or disabled for distribution (enabled or disabled). The last column indicates the scope of distribution for the application (logical, physical, or both).

Note The show cfs application command only displays applications registered with CFS. Conditional services that use CFS do not appear in the output unless these services are running.

switch# show cfs application

----------------------------------------------

Application Enabled Scope

----------------------------------------------

ntp No Physical-all

fscm Yes Physical-fc

rscn No Logical

fctimer No Physical-fc

syslogd No Physical-all

callhome No Physical-all

fcdomain Yes Logical

device-alias Yes Physical-fc

Total number of entries = 8

The show cfs application name command displays the details for a particular application. It displays the enabled/disabled state, timeout as registered with CFS, merge capability (if it has registered with CFS for merge support), and lastly the distribution scope.

switch# show cfs application name fscm

Enabled : Yes

Timeout : 100s

Merge Capable : No

Scope : Physical-fc

Locking the Network

When you configure (first time configuration) a feature (or application) that uses the CFS infrastructure, that feature starts a CFS session and locks the network. When a network is locked, the switch software allows configuration changes to this feature only from the switch holding the lock. If you make configuration changes to the feature from another switch, the switch issues a message to inform the user about the locked status. The configuration changes are held in a pending database by that application.

If you start a CFS session that requires a network lock but forget to end the session, an administrator can clear the session. If you lock a network at any time, your user name is remembered across restarts and switchovers. If another user (on the same machine) tries to perform configuration tasks, that user’s attempts are rejected.

Verifying CFS Lock Status

switch# show cfs lock name ntp

Scope : Physical

--------------------------------------------------------------------

Switch WWN IP Address User Name User Type

--------------------------------------------------------------------

20:00:00:05:30:00:6b:9e 10.76.100.167 admin CLI/SNMP v3

Total number of entries = 1

Committing Changes

A commit operation saves the pending database for all application peers and releases the lock for all switches.

In general, the commit function does not start a session, only a lock function starts a session. However, an empty commit is allowed if configuration changes are not previously made. In this case, a commit operation results in a session that acquires locks and distributes the current database.

When you commit configuration changes to a feature using the CFS infrastructure, you receive a notification about one of the following responses:

- One or more external switches report a successful status—The application applies the changes locally and releases the network lock.

- None of the external switches report a successful state—The application considers this state a failure and does not apply the changes to any switch in the network. The network lock is not released.

You can commit changes for a specified feature by entering the commit command for that feature.

Discarding Changes

If you discard configuration changes, the application flushes the pending database and releases locks in the network. Both the abort and commit functions are only supported from the switch from which the network lock is acquired.

You can discard changes for a specified feature by using the abort command for that feature.

Saving the Configuration

Configuration changes that have not been applied yet (still in the pending database) are not shown in the running configuration. The configuration changes in the pending database overwrite the configuration in the effective database when you commit the changes.

Caution If you do not commit the changes, they are not saved to the running configuration.

The CISCO-CFS-MIB contains SNMP configuration information for any CFS-related functions. Refer to the Cisco Nexus 5000 Series MIB Quick Reference for more information on this MIB.

Clearing a Locked Session

You can clear locks held by an application from any switch in the network to recover from situations where locks are acquired and not released. This function requires Admin permissions.

Caution Exercise caution when using this function to clear locks in the network. Any pending configurations in any switch in the network is flushed and lost.

CFS Regions

This section contains the following topics:

- About CFS Regions

- Example Scenario

- Managing CFS Regions

About CFS Regions

A CFS region is a user-defined subset of switches for a given feature or application in its physical distribution scope. When a network spans a vast geography, you may need to localize or restrict the distribution of certain profiles among a set of switches based on their physical proximity. CFS regions allow you to create multiple islands of distribution within the network for a given CFS feature or application. CFS regions are designed to restrict the distribution of a feature’s configuration to a specific set or grouping of switches in a network.

Note You can only configure a CFS region based on physical switches. You cannot configure a CFS region in a VSAN.

Example Scenario

The Call Home application triggers alerts to network administrators when a situation arises or something abnormal occurs. When the network covers many geographies, and there are multiple network administrators who are each responsible for a subset of switches in the network, the Call Home application sends alerts to all network administrators regardless of their location. For the Call Home application to send message alerts selectively to network administrators, the physical scope of the application has to be fine tuned or narrowed down, which is achieved by implementing CFS regions.

CFS regions are identified by numbers ranging from 0 through 200. Region 0 is reserved as the default region, and contains every switch in the network. You can configure regions from 1 through 200. The default region maintains backward compatibility.

If the feature is moved, that is, assigned to a new region, its scope is restricted to that region; it ignores all other regions for distribution or merging purposes. The assignment of the region to a feature has precedence in distribution over its initial physical scope.

You can configure a CFS region to distribute configurations for multiple features. However, on a given switch, you can configure only one CFS region at a time to distribute the configuration for a given feature. Once you assign a feature to a CFS region, its configuration cannot be distributed within another CFS region.

Managing CFS Regions

This section describes how to manage a CFS region. A set of commands are used to complete the following tasks:

- Creating CFS Regions

- Assigning Applications to CFS Regions

- Moving an Application to a Different CFS Region

- Removing an Application from a Region

- Deleting CFS Regions

Creating CFS Regions

To create a CFS region, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs region region-id

Creates a region.

Assigning Applications to CFS Regions

To assign an application on a switch to a region, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs region region-id

Creates a region.

Step 3

switch(config-cfs-region)# ntp

switch(config-cfs-region)# callhome

Adds application(s).

Moving an Application to a Different CFS Region

To move an application for example, from Region 1 (originating region) with NTP and Call Home applications assigned to it, to Region 2 (target region), perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs region region-id

Enters CFS region configuration submode.

Step 3

switch(config-cfs-region)# ntp

switch(config-cfs-region)# callhome

Indicates application(s) to be moved into Region 2 that originally belong to Region 1. For example, here, the NTP and Call Home applications are moved to Region 2.

Note If you try adding an application to the same region more than once, you see the error message, “Application already present in the same region.”

Removing an Application from a Region

Removing an application from a region is the same as moving the application back to the default region or to Region 0, that is, bringing the entire network into the scope of distribution for the application.

To remove applications from a region, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs region region-id

Enters CFS region configuration submode.

Step 3

switch(config-cfs-region)# no ntp

switch(config-cfs-region)# no callhome

Removes application(s) that belong to the region.

Deleting CFS Regions

Deleting a region is nullifying the region definition. All the applications bound by the region are released back to the default region by deleting that region.

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# no cfs region region-id

Deletes the region.

Note After Step 2, you see the warning, “All the applications in the region will be moved to the default region.”

Configuring CFS Over IP

The following sections provide information about configuring CFS over IP:

- Enabling CFS Over IP

- Verifying the CFS Over IP Configuration

- Configuring IP Multicast Address for CFS over IP

- Verifying IP Multicast Address Configuration for CFS over IP

Enabling CFS Over IP

Note CFS cannot distribute over both IPv4 and IPv6 from the same switch.

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs ipv4 distribute

Globally enables CFS over IPv4 for all applications on the switch.

switch(config)# no cfs ipv4 distribute

Disables (default) CFS over IPv4 on the switch.

To enable or disable CFS over IPv6, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs ipv6 distribute

Globally enables CFS over IPv6 for all applications on the switch.

switch(config)# no cfs ipv6 distribute

Disables (default) CFS over IPv6 on the switch.

Verifying the CFS Over IP Configuration

To verify the CFS over IP configuration, use the show cfs status command.

switch# show cfs status

Distribution : Enabled

Distribution over IP : Enabled - mode IPv4

IPv4 multicast address : 239.255.70.83

IPv6 multicast address : ff15::efff:4653

Configuring IP Multicast Address for CFS over IP

All CFS over IP enabled switches with similar multicast addresses form one CFS over IP network. CFS protocol-specific distributions, such as the keepalive mechanism for detecting network topology changes, use the IP multicast address to send and receive information.

Note CFS distributions for application data use directed unicast.

You can configure a CFS over IP multicast address value for either IPv4 or IPv6. The default IPv4 multicast address is 239.255.70.83 and the default IPv6 multicast address is ff13:7743:4653.

To configure an IP multicast address for CFS over IPv4, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs ipv4 mcast-address ipv4-address

Distribution over this IP type will be affected

Change multicast address for CFS-IP ?

Are you sure? (y/n) [n] y

Configures the IPv4 multicast address for CFS distribution over IPv4. The ranges of valid IPv4 addresses are 239.255.0.0 through 239.255.255.255 and 239.192/16 through 239.251/16.

switch(config)# no cfs ipv4 mcast-address ipv4-address

Distribution over this IP type will be affected

Change multicast address for CFS-IP ?

Are you sure? (y/n) [n] y

Reverts to the default IPv4 multicast address for CFS distribution over IPv4. The default IPv4 multicast address for CFS is 239.255.70.83.

To configure an IP multicast address for CFS over IPv6, perform this task:

Command

Purpose

Step 1

switch# configure

switch(config)#

Enters configuration mode.

Step 2

switch(config)# cfs ipv6 mcast-address ipv6-address

Distribution over this IP type will be affected

Change multicast address for CFS-IP ?

Are you sure? (y/n) [n] y

Configures the IPv6 multicast address for CFS distribution over IPv6. The range of valid IPv6 addresses is ff15::/16 (ff15::0000:0000 through ff15::ffff:ffff) and ff18::/16 (ff18::0000:0000 through ff18::ffff:ffff).

switch(config)# no cfs ipv6 mcast-address ipv6-address

Distribution over this IP type will be affected

Change multicast address for CFS-IP ?

Are you sure? (y/n) [n] y

Reverts to the default IPv6 multicast address for CFS distribution over IPv6. The default IPv6 multicast address for CFS over IP is ff15::efff:4653.

Verifying IP Multicast Address Configuration for CFS over IP

To verify the IP multicast address configuration for CFS over IP, use the show cfs status command:

switch# show cfs status

Fabric distribution Enabled

IP distribution Enabled mode ipv4

IPv4 multicast address : 10.1.10.100

IPv6 multicast address : ff13::e244:4754

Displaying CFS Distribution Information

switch# show cfs merge status name ntp

Physical Merge Status: Failed

Local Fabric

---------------------------------------------------------

Switch WWN IP Address

---------------------------------------------------------

20:00:00:05:30:00:6b:9e 10.76.100.167 [Merge Master]

Remote Fabric

---------------------------------------------------------

Switch WWN IP Address

---------------------------------------------------------

20:00:00:0e:d7:00:3c:9e 10.76.100.169 [Merge Master]

The show cfs peers command output displays all the switches in the physical network in terms of the switch WWN and the IP address. The local switch is indicated as Local.

switch# show cfs peers

Physical Fabric

-------------------------------------------------

Switch WWN IP Address

-------------------------------------------------

20:00:00:05:30:00:6b:9e 10.76.100.167 [Local]

20:00:00:0e:d7:00:3c:9e 10.76.100.169

Total number of entries = 2

The show cfs peers name command displays all the peers for which a particular application is registered with CFS. The command output shows all the peers for the physical scope or for each of the valid VSANs on the switch, depending on the application scope. For physical scope, the switch WWNs for all the peers are indicated. The local switch is indicated as Local.

switch# show cfs peers name ntp

Scope : Physical

-------------------------------------------------

Switch WWN IP Address

-------------------------------------------------

20:00:00:44:22:00:4a:9e 172.22.92.27 [Local]

20:00:00:05:30:01:1b:c2 172.22.92.215

The following example show cfs peers name command output displays all the application peers (all switches in which that application is registered). The local switch is indicated as Local.

switch# show cfs peers name port-security

Scope : Logical [VSAN 1]

-----------------------------------------------------------

Domain Switch WWN IP Address

-----------------------------------------------------------

124 20:00:00:44:22:00:4a:9e 172.22.92.27 [Local]

98 20:00:00:05:30:01:1b:c2 172.22.92.215

Total number of entries = 2

Scope : Logical [VSAN 3]

-----------------------------------------------------------

Domain Switch WWN IP Address

-----------------------------------------------------------

224 20:00:00:44:22:00:4a:9e 172.22.92.27 [Local]

151 20:00:00:05:30:01:1b:c2 172.22.92.215

Total number of entries = 2

Default Settings

Table 1-1 Default CFS Parameters

Parameters

Default

CFS distribution on the switch

Enabled.

Database changes

Implicitly enabled with the first configuration change.

Application distribution

Differs based on application.

Commit

Explicit configuration is required.

CFS over IP

Disabled.

IPv4 multicast address

239.255.70.83.

IPv6 multicast address

Configuring FCoE

Fibre Channel over Ethernet (FCoE) provides a method of transporting Fibre Channel traffic over a physical Ethernet connection. FCoE requires the underlying Ethernet to be full duplex and to provide lossless behavior for Fibre Channel traffic.

This chapter describes how to configure FCoE and includes the following sections:

- Information About FCoE

- Configuring FCoE

- Configuring LLDP

- Verifying FCoE Configuration

Information About FCoE

In Cisco Nexus 5000 Series switches, FCoE is supported on all 10-Gigabit Ethernet interfaces.

To use FCoE, the switch must be directly connected to the server and the server port must terminate the Ethernet with a converged network adapter.

This section includes the following topics:

- Licensing Requirements

- Converged Network Adapters

- DCBX Capabilities

- DCE Bridging Capability Exchange Protocol

- DCBX Feature Negotiation

- Ethernet Frame Formats

Licensing Requirements

On Cisco Nexus 5000 Series switches, FCoE capability is included in the Storage Protocol Services License.

Before using FCoE capabilities, ensure that:

- The correct license is installed (N5010SS or N5020SS).

- FCoE is activated by entering the feature fcoe command in configuration mode.

Converged Network Adapters

The following types of converged network adapters (CNAs) are available:

- Hardware adapter

– Works with the existing FC HBA driver and LAN NIC driver in the server.

– Server operating system view of the network is unchanged; the CNA presents a SAN interface and a LAN interface to the operating system.

- FCoE software stack

– Runs on existing 10-Gigabit Ethernet adapters.

FCoE offers a number of optional capabilities. The available capabilities and their configurable values are negotiated between the switch and the adapter. To accomplish this, the adapter and the switch exchange information using the Data Center Bridging Exchange Protocol (DCBX).

To reduce configuration errors and simplify administration. you can configure the switch to distribute the configuration data to all the connected adapters.

DCBX Capabilities

The DCBX capabilities supported by Cisco Nexus 5000 Series switches are described in the following topics:

- FCoE

- Priority Flow Control

- Logical Link Up/Down

FCoE

By default, each Ethernet interface attempts to enable FCoE capability by advertising the capability to the adapter.

If the FCoE negotiation fails, you can configure the switch to disable FCoE or to force-enable FCoE for this interface.

Priority Flow Control

The priority flow control (PFC) capability allows you to apply pause functionality to specific classes of traffic. PFC decides whether to apply pause based on the IEEE 802.1p CoS value. When the switch enables PFC, it configures the connected adapter to apply the pause functionality to packets with specific CoS values.

By default, the switch negotiates to enable the PFC capability. If the negotiation succeeds, PFC is enabled and link-level flow control remains disabled (regardless of its configuration settings).

If the PFC negotiation fails, you can either force PFC to be enabled on the interface or you can enable IEEE 802.x link-level flow control.

Link-level flow control can be enabled on the interface only if PFC is not enabled. For additional information about link-level flow control, see the “Link-Level Flow Control” section.

Logical Link Up/Down

On a native Fibre Channel link, some configuration actions (such as changing the VSAN) require you to reset the interface status. The switch achieves the reset by disabling the interface, and then immediately reenabling the interface.

If an Ethernet link is providing FCoE service, the physical link should not be reset because this action is disruptive to all traffic on the link.

The logical link up/down feature provides the ability to reset an individual virtual link. The switch sends a DCBX message to request the adapter to reset only the virtual Fibre Channel interface.

Note If the adapter does not support the logical link level up/down feature, the adapter resets the physical link. In this case, all traffic on the Ethernet interface is disrupted.

DCE Bridging Capability Exchange Protocol

DCBX protocol is an extension of the Link Layer Discovery Protocol (LLDP). DCBX end points exchange request and acknowledgment messages. For flexibility, parameters are coded in a type-length-value (TLV) format.

DCBX runs on the physical Ethernet link between the Cisco Nexus 5000 Series switch and the converged network adapter on the server. By default, DCBX is enabled on Ethernet interfaces. When an Ethernet interface is brought up, the switch automatically starts to communicate with the adapter.

During normal operation of FCoE between the switch and the adapter, the DCBX protocol provides link-error detection.

DCBX is also used to negotiate capabilities between the switch and the adapter and to send configuration values to the adapter.

Adapters connected to a Cisco Nexus 5000 Series switch are programmed to accept the configuration values sent by the switch, allowing the switch to distribute configuration values to all attached adapters. The capability reduces the possibility of configuration error and simplifies administration of the adapters.

The switch provides a manual configuration override for each parameter negotiated using DCBX. The override takes effect if the adapter does not support DCBX, or if the adapter does not support the specific capability requested by the switch.

DCBX Feature Negotiation

The switch and adapter exchange capability information and configuration values. The Cisco Nexus 5000 Series switches support the following capabilities:

- FCoE

If the adapter supports FCoE capability, the switch sends the IEEE 802.1p CoS value to be used with FCoE packets.

- Priority Flow Control (PFC)

If the adapter supports PFC, the switch sends the IEEE 802.1p CoS values to be enabled with PFC.

- Ethernet logical link up and down signal

- FCoE logical link up and down signal

The following rules determine whether the negotiation results in a capability being enabled:

- If a capability and its configuration values match between the switch and the adapter, the feature is enabled.

- If the capability matches, but the configuration values do not match:

– If the adapter is configured to accept the switch configuration value, the capability is enabled using the switch value.

– If the adapter is not configured to accept the switch configuration value, the capability remains disabled.

- If the adapter does not support the DCBX capability, the capability remains disabled.

- If the adapter does not implement DCBX, all capabilities remain disabled.

Note The Cisco Nexus 5000 Series switch provides CLI commands to manually override the results of the negotiation with the adapter. On a per-interface basis, you can force capabilities to be enabled or disabled. For additional information, see the “Configuring FCoE” section.

Ethernet Frame Formats

Ethernet frames sent by the switch to the adapter may include the IEEE 802.1Q tag. This tag includes a field for the CoS value used by PFC. The IEEE 802.1Q tag also includes a VLAN field, currently not used by the Cisco Nexus 5000 Series switch.

The switch will always accept tagged or untagged frames from the adapter.

If the FCoE capability is enabled between the switch and the adapter:

- All Ethernet frames sent to the adapter include IEEE 802.1Q tags.

– The VLAN ID field is always set to 0.

– The CoS field is set to the CoS value of the associated system class. For additional information, see the “System Classes” section.

- The switch accepts tagged or untagged frames from the adapter.

If the FCoE capability is disabled between the switch and the adapter:

- Ethernet frames sent to the adapter do not include IEEE 802.1Q tags.

- The switch accepts tagged or untagged frames from the adapter.

Configuring FCoE

This section contains the following topics:

- Enabling FCoE

- Enabling FCoE on Ethernet Interfaces

- Configuring Priority Flow Control

- Configuring IEEE 802.3x Link-Level Flow Control

Enabling FCoE

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# feature fcoe

Enables the FCoE capability.

The following example shows how to enable FCoE on the switch:

switch# configure terminal

switch(config)# feature fcoe

FC license checked out successfully

Enabling FCoE on Ethernet Interfaces

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Enters interface configuration mode for the specified interface.

Step 3

switch(config-if)# fcoe mode { auto | on }

When you set the FCoE parameter to auto, the interface negotiates the setting with the connected adapter. FCoE will not be enabled on the interface if the adapter does not support FCoE.

If the mode is set it to on, the negotiation result is ignored and FCoE is set to enabled on the interface.

Command

Purpose

switch(config-if)# no fcoe mode [auto | on]

Disables FCoE capability for this interface.

This example shows how to disable FCoE for an Ethernet interface:

switch# configure terminal

switch(config)# interface ethernet 1/4

switch(config-if)# no fcoe mode auto

The fcoe command can only be applied to a physical Ethernet interface.

Configuring Priority Flow Control

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Specifies the interface to be changed.

Step 3

switch(config-if)# priority-flow-control mode { auto | on }

Sets PFC mode for the selected interface.

Specify auto to negotiate PFC capability.

Specify on to force-enable PFC.

The following example shows how to force-enable PFC on an interface:

switch# configure terminal

switch(config)# interface ethernet 1/2

switch(config-if)# priority-flow-control mode on

To disable PFC capability for this interface, perform this task:

Command

Purpose

switch(config-if)# no priority-flow-control mode [ auto | on ]

Disables the PFC capability for this interface.

Configuring IEEE 802.3x Link-Level Flow Control

By default, link-level flow control capability on Ethernet interfaces is disabled. Only enable the link-level flow control capability if PFC is disabled on the interface.

To configure link-level flow control, see the “Configuring IEEE 802.3x Link-Level Flow Control” section.

Configuring LLDP

This section shows how to configure LLDP both globally and on individual interfaces. This section includes the following topics:

- Configuring Global LLDP Commands

- Configuring Interface LLDP Commands

Configuring Global LLDP Commands

You can set global LLDP settings. These settings include the length of time before discarding LLDP information received from peers, the length of time to wait before performing LLDP initialization on any interface, and the rate at which LLDP packets are sent.

To configure LLDP settings, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# lldp {holdtime seconds | reinit seconds | timer seconds}

Configures LLDP options.

Use the holdtime option to set the length of time (10 to 255 seconds, default 120 seconds) that a device should save LLDP information received before discarding it.

Use the reinit option to set the length of time (1 to 10 seconds, default 2 seconds) to wait before performing LLDP initialization on any interface.

Use the timer option to set the rate (5 to 254 seconds, default 30 seconds) at which LLDP packets are sent.

The following example shows how to set LLDP timer option to 15 seconds:

switch# configure terminal

switch(config)# lldp timer 15

Command

Purpose

switch(config)# no lldp {holdtime | reinit | timer}

Reset the LLDP values to their defaults.

Configuring Interface LLDP Commands

To configure the LLDP feature for a physical Ethernet interface, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Selects the interface to change.

Step 3

switch(config-if)# [ no ] lldp { receive | transmit }

Sets the selected interface to either receive or transmit.

The no form of the command disables the LLDP transmit or receive.

switch# configure terminal

switch(config)# interface ethernet 1/2

switch(config-if)# no lldp transmit

switch(config-if)# no lldp receive

You can only apply this command to a physical Ethernet interface.

Verifying FCoE Configuration

Command

Purpose

switch# show fcoe

Displays whether FCoE is enabled on the switch.

switch# show lldp

Displays LLDP configuration.

The following example shows how to verify that the FCoE capability is enabled:

switch# show fcoe

FCoE/FC feature is desired.

The following example shows how to display LLDP interface information:

switch# show lldp interface ethernet 1/2

tx_enabled: TRUE

rx_enabled: TRUE

dcbx_enabled: TRUE

Port MAC address: 00:0d:ec:a3:5f:48

Remote Peers Information

No remote peers exist

The following example shows how to display LLDP neighbor information:

switch# show lldp neighbors

The following example shows how to display LLDP timer information:

switch# show lldp timers

LLDP Timers

holdtime 120 seconds

reinit 2 seconds

msg_tx_interval 30 seconds

The following example shows how to display LLDP counters:

switch# show lldp traffic

Configuring QoS

This chapter describes how to configure the quality of service (QoS) features on the Cisco Nexus 5000 Series switch.

This chapter includes the following sections:

- Information About QoS

- Configuration Guidelines and Limitations

- Configuring PFC and LLC

- Configuring System Classes

- Configuring QoS on Interfaces

Information About QoS

The Cisco Nexus 5000 Series switch provides QoS capabilities such as traffic prioritization and egress bandwidth allocation.

The default QoS configuration on the switch provides lossless service for Fibre Channel and Fibre Channel Over Ethernet (FCoE) traffic and best-effort service for Ethernet traffic. QoS can be configured to provide additional classes of service for Ethernet traffic. Cisco Nexus 5000 Series QoS features are configured using Cisco Modular QoS CLI (MQC).

This section includes the following topics:

- MQC

- System Classes

- Default System Classes

- Link-Level Flow Control

- Priority Flow Control

- MTU

- Trust Boundaries

- Ingress Policies

- Egress Policies

- QoS for Multicast Traffic

- Policy for Fibre Channel Interfaces

- QoS for Traffic Directed to the CPU

MQC

The Cisco Modular QoS CLI (MQC) provides a standard set of commands for configuring QoS.

You can use MQC to define additional traffic classes and to configure QoS policies for the whole system and for individual Ethernet interfaces. Configuring a QoS policy with MQC consists of the following steps:

1. Define traffic classes using the class-map command.

The class map classifies incoming or outgoing packets based on matching criteria, such as the IEEE 802.1p CoS value. Unicast and multicast packets are classified.

2. Associate policies or actions with each class of traffic using the policy-map command.

The policy map defines a set of actions to take on the associated traffic class, such as limiting the bandwidth or dropping packets.

3. Attach policies to MQC targets using the service-policy command.

An MQC target is an entity (such as an Ethernet interface) that represents a flow of packets. A service policy associates a policy map with an MQC target, and specifies whether to apply the policy on incoming or outgoing packets. This enables the configuration of interface-specific QoS policies such as policing and bandwidth allocation.

System Classes

The system class is a new type of MQC target. A service policy can associate a policy map with a system class, which enables application of a QoS policy across the whole switch.

Parameters in system classes need to be configured consistently across the switch and the whole network to ensure that packets in a specific traffic class receive consistent treatment as they are transported across the network.

To ensure QoS consistency (and for ease of configuration), the switch distributes the system class parameter values to all its attached network adapters using the DCBX protocol. For additional information about communication between the switch and adapters, see the “DCE Bridging Capability Exchange Protocol” section.

If service policies are configured at the interface level, the interface-level policy always takes precedence over system class configuration or defaults.

The following QoS parameters can be specified for a system class:

- Drop

No drop specifies lossless service for the system class. Drop specifies that tail drop is used when a queue for this system class is full.

- MTU

The system class MTU defines the maximum packet size for any packet classified into the system class. Each system class has a default MTU and the system class MTU is configurable.

- Match CoS value

The match CoS value specifies the IEEE 802.1p CoS value to associate with this system class.

- Bandwidth and priority

Sets the bandwidth and priority configuration values for this system class. The system class values are used as the default values for all interfaces.

Default System Classes

The Cisco Nexus 5000 Series switch provides the following default system classes:

- FCoE system class

All Fibre Channel and FCoE control and data traffic is automatically classified into the FCoE system class, which provides no-drop service.

This class is created automatically when the system starts up (the class is named class-fcoe in the CLI). You cannot delete this class, and you can only modify the IEEE 802.1p CoS value to associate with this class.

The switch classifies packets into the FCoE system class as follows:

– FCoE traffic is classified based on EtherType.

– Native Fibre Channel traffic is classified based on the physical interface type.

- Drop system class

By default, all unicast and multicast Ethernet traffic is classified into the default drop system class.

This class is created automatically when the system starts up (the class is named class-default in the CLI). You cannot delete this class and you cannot change the CoS value associated with the default class.

There are two reserved system classes for internal system use.

Link-Level Flow Control

The IEEE 802.3x link-level flow control capability allows a congested receiver to communicate the far end to pause its data transmission for a short period of time. The link-level flow control feature applies to all the traffic on the link.

The transmit and receive directions are separately configurable. By default, link-level flow control is disabled for both directions.

On the Cisco Nexus 5000 Series switch, Ethernet interfaces do not auto-detect the link-level flow control capability. You must configure the capability explicitly on the Ethernet interfaces.

On each Ethernet interface, the switch can enable either priority flow control or link-level flow control (but not both).

Priority Flow Control

The priority flow control (PFC) capability allows you to apply pause functionality to specific classes of traffic on a link (instead of all the traffic on the link). PFC applies pause functionality based on the IEEE 802.1p CoS value. When the switch enables PFC, it communicates to the adapter which CoS values to apply the pause.

Ethernet interfaces use PFC to provide lossless service to no-drop system classes. PFC implements Pause frames on a per-class basis and uses the IEEE 802.1p CoS value to identify the classes that require lossless service.

In the switch, each system class has an associated IEEE 802.1p CoS value (assigned by default or configured on the system class). If PFC is enabled, the switch sends the no-drop CoS values to the adapter, which then applies PFC to these CoS values.

The default CoS value for the FCoE system class is 3 and this value is configurable. The default CoS value for the default drop system class is 0 and this value is configurable.

If PFC is not enabled on an interface, you can enable IEEE 802.3X link-level pause. By default, link-level pause is disabled.

MTU

The Cisco Nexus 5000 Series switch is a Layer 2 switch, and it does not support packet fragmentation. MTU configuration mismatch between ingress and egress interfaces may result in packets being truncated.

When configuring MTU, follow these guidelines:

- MTU is specified per system class. You cannot configure MTU on the interfaces.

- Fibre Channel and FCoE payload MTU is 2112 bytes across the switch. As a result, the rxbufsize for Fibre Channel interfaces is fixed at 2112 bytes. If the Cisco Nexus 5000 Series switch receives an rxbufsize from a peer different than 2112 bytes, it will fail ELP negotiation and not bring the link up.

- The system jumbomtu command defines the upper bound of any MTU in the system. System jumbo MTU has a default value of 9216 bytes. The minimum MTU is 2240 bytes and the maximum MTU is 9216 bytes.

- The system class MTU sets the MTU for all packets in the class. The system class MTU cannot be configured larger than the global jumbo MTU.

- The FCoE system class (for Fibre Channel and FCoE traffic) has a default MTU of 2240 bytes. This value cannot be modified.

- The default drop system class has a default MTU of 1500 bytes. You can configure this value.

- The switch sends the MTU configuration to network adapters that support DCBXP.

Trust Boundaries

The trust boundary is enforced by the incoming interface as follows:

- All Fibre Channel and virtual Fibre Channel interfaces are automatically classified into the FCoE system class.

- By default, all Ethernet interfaces are trusted interfaces. A packet tagged with a 802.1p CoS value is classified into a system class using the value in the packet.

- Any packet not tagged with an 802.1p CoS value is classified into the default drop system class. If the untagged packet is sent over a trunk, it is tagged with the default untagged CoS value, which is zero.

- You can override the default untagged CoS value for an Ethernet interface or port channel.

After the system applies the untagged CoS value, QoS functions the same as for a packet that entered the system tagged with the CoS value.

Ingress Policies

You can associate an ingress policy map with an Ethernet interface, to guarantee bandwidth for the specified traffic class or to specify a priority queue.

The ingress policy is applied in the adapter to all outgoing traffic that matches the specified CoS value.

When you configure an ingress policy for an interface, the switch sends the configuration data to the adapter. If the adapter does not support DCBX protocol (or the ingress policy TLVs), the ingress policy configuration is ignored.

Egress Policies

You can associate an egress policy map with an Ethernet interface, to guarantee the bandwidth for the specified traffic class or to configure the egress queues.

The bandwidth allocation limit applies to all traffic on the interface (including any FCoE traffic).

Each Ethernet interface supports up to eight queues (one for each system class). The queues have the following default configuration:

- Queue zero is configured as a strict priority queue. Control traffic destined for the CPU uses this queue.

- FCoE traffic (traffic that maps to the FCoE system class) is assigned a queue. This queue uses WRR scheduling with 50 percent of the bandwidth.

- Standard Ethernet traffic (in the default drop system class) is assigned a queue. This queue uses WRR scheduling with 50 percent of the bandwidth.

If you add a system class, a queue is assigned to the class. You must reconfigure the bandwidth allocation on all affected interfaces. Bandwidth is not dedicated automatically to user-defined system classes.

You can configure an additional strict priority queue. This queue is serviced before all other queues except queue zero (which carries control traffic, not data traffic).

QoS for Multicast Traffic

The system provides six multicast queues per interface and allocates one queue for each system class. By default, all multicast Ethernet traffic is classified into the default drop system class. This traffic is serviced by one multicast queue.

The optimized multicast feature allows use of the unused multicast queues, to achieve better throughput for multicast frames. If optimized multicast is enabled for the default drop system class, the system will use all six queues to service the multicast traffic (all six queues are given equal priority).

If you define a new system class. a dedicated multicast queue is assigned for this class. This queue is removed from the set of queues available for optimized multicast.

The optimized multicast feature achieves better throughput for multicast frames and improves performance for multicast frames that are less than 256 bytes long.

Note Optimized multicast is supported on the BF and later versions of the Cisco Nexus 5020 switch. To verify the model version, enter the show module 1 command. The model version is the last two characters of the model number. Optimized multicast is supported on all versions of the Cisco Nexus 5010 switch.

The system provides two predefined class maps for matching broadcast or multicast traffic. These class maps are convenient for creating separate policy maps for unicast and multicast traffic. The predefined class maps are as follows:

- class-all-flood

The class-all-flood class map matches all broadcast, multicast and unknown unicast traffic (across all CoS values). If you configure a policy map with the class-all-flood class map, the system automatically utilizes all available multicast queues for this traffic.

- class-ip-multicast

The class-ip-multicast class map matches all IP multicast traffic. Policy options configured in this class map apply to traffic across all Ethernet CoS values. For example, if you enable optimized multicast for this class, the IP multicast traffic for all CoS values is optimized.

If you configure this class as a no-drop class, the priority flow control capability is applied across all Ethernet CoS values. In this configuration, pause will be applied to unicast and multicast traffic.

Note Only one of these predefined classes can be configured in the system QoS policy.

Policy for Fibre Channel Interfaces

The egress queues are not configurable for native Fibre Channel interfaces. Two queues are available as follows:

- A strict priority queue to serve high-priority control traffic.

- A queue to serve all data traffic and low-priority control traffic.

QoS for Traffic Directed to the CPU

The switch automatically applies QoS policies to traffic that is directed to the CPU to ensure that the CPU is not flooded with packets. Control traffic, such as BPDU frames, is given higher priority to ensure delivery.

Configuration Guidelines and Limitations

Switch resources (such as buffers, virtual output queues, and egress queues) are partitioned based on the default and user-defined system classes. The switch software automatically adjusts the resource allocation to accommodate the configured system classes.

To maintain optimal switch performance, follow these guidelines when configuring system classes and policies:

- If less than four Ethernet classes are defined, up to two of these classes can be configured as no-drop classes . If more than four Ethernet classes are defined, only one of these classes can be configured as a no-drop class. The default drop class is counted as an Ethernet class.

- If priority flow control is enabled on an Ethernet interface, pause will never be applied to traffic with a drop system class. PFC does not apply pause to drop classes and the link-level pause feature is never enabled on an interface with PFC.

- All FCoE traffic on an Ethernet interface is mapped to one no-drop system class. By default, this class is associated with CoS value 3, although you can configure a different value. If you configure standard Ethernet traffic to use the same CoS value as FCoE, the switch does not apply priority flow control to the standard Ethernet traffic. This traffic is mapped to the default drop system class.

- The CoS value 0 is reserved for the default drop system class. This value cannot be mapped to any other class.

When configuring Ethernet port channels, note the following guidelines:

- Service policies configured on port channel interfaces are applied to all members of the port channel. Service policies configured on individual member interfaces are ignored.

- Priority flow control is configured on the individual member interfaces of a port channel. The PFC configuration must be consistent across all members of the port channel for the port channel to become operational.

Configuring PFC and LLC

Cisco Nexus 5000 Series switches support PFC and LLC on Ethernet interfaces. The Ethernet interface can operate in two different modes: FCoE mode or standard Ethernet mode.

If the interface is operating in FCoE mode, the Ethernet link is connected at the server port using a converged network adapter (CNA). Refer to Chapter 1, “Configuring FCoE” for information about configuring PFC and LLC when the interface is operating in FCoE mode.

If the interface is operating in standard Ethernet mode, the Ethernet link is connected at the server port with a standard Ethernet network adapter (NIC). The network adapter must support DCBX protocol for PFC or ingress policing to be supported on the interface.

Note You must configure a no-drop Ethernet system class for PFC to operate on Ethernet traffic (PFC will be applied to traffic that matches the CoS value configured for this class).

Configuring PFC and LLC for standard Ethernet is covered in the following topics:

- Configuring Priority Flow Control

- Configuring IEEE 802.3x Link-Level Flow Control

Configuring Priority Flow Control

By default, Ethernet interfaces negotiate PFC capability with the network adapter using DCBX protocol. When PFC is enabled, PFC is applied to traffic that matches the CoS value configured for the no-drop Ethernet class.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Specifies the interface to be changed.

Step 3

switch(config-if)# priority-flow-control mode { auto | on }

Sets PFC mode for the selected interface.

Specify on to force-enable PFC.

Specify auto to negotiate PFC capability.

Note Priority flow control is configured on the individual member interfaces of a port channel. The PFC configuration must be consistent across all members of the port channel for the port channel to become operational.

Command

Purpose

switch(config-if)# no priority-flow-control mode

Disables the PFC setting for the selected interface.

Configuring IEEE 802.3x Link-Level Flow Control

By default, link-level flow control capability on Ethernet interfaces is disabled. You can enable link-level flow-control capability for the transmit and receive directions. To enable link-level flow control capability, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface type slot / port

Specifies the interface to be changed.

Step 3

switch(config-if)# flowcontrol [ receive { on | off }] [ transmit { on | off }]

Enables IEEE 802.3x link-level flow control for the selected interface. Set receive and/or transmit on or off.

The following example enables link-level flow control frames on an interface:

switch# configure terminal

switch(config)# interface ethernet 1/2

switch(config-if)# flowcontrol receive on transmit on

To disable link-level flow control, perform this task:

Command

Purpose

switch(config-if)# no flowcontrol [ receive { on | off }] [ transmit { on | off }]

Disables 802.3x link-level flow control for the selected interface.

Configuring System Classes

This section describes how to configure system classes on the switch. The steps to configure a system class are described in the following topics:

- Configuring Class Maps

- Configuring Policy Maps

- Creating the System Service Policy

- System Class Example

- Enable Link Level Flow Control Example

- Enabling Jumbo MTU

- Verifying Jumbo MTU

Configuring Class Maps

The class-map command creates a named object that represents a class of traffic. In the class map, you specify a set of match criteria for classifying the packets. For system classes, the only match criteria supported is match cos.

If a system class is configured with no-drop function, the match cos command serves an additional purpose. The switch sends the CoS value to the adapter, so that the adapter will apply PFC Pause for this CoS value.

The FCoE system class has a default CoS value of 3. You can add a match cos configuration to the FCoE system class to set a different CoS value. PFC Pause will be applied to traffic that matches the new value.

To configure a class map for a system class, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# class-map name

Creates a named object that represents a class of traffic. Class map names can contain alphabetic, hyphen, or underscore characters, are case sensitive, and can be up to 40 characters.

Step 3

switch(config-cmap)# match cos cos-value

Specifies the CoS value to match for classifying packets into this class. You can configure a CoS value in the range of 1 to 7.
).

Configuring Policy Maps

The policy-map command is used to create a named object representing a set of policies that are to be applied to a set of traffic classes.

The switch provides two default system classes: a no-drop class for lossless service and a drop class for best-effort service. You can define up to four additional system classes for Ethernet traffic.

You need to create a policy map to specify the policies for any user-defined class. In the policy-map, you can configure the QoS parameters for each class. You can use the same policy map to modify the configuration of the default classes.

Note Before creating the policy map, define a class map for each new system class.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# policy-map name

Creates a named object representing a set of policies that are to be applied to a set of traffic classes. Policy-map names can contain alphabetic, hyphen, or underscore characters, are case sensitive, and can be up to 40 characters.

Step 3

switch(config-pmap)# class class-name

Associates a class map with the policy map, and enters configuration mode for the specified system class.

Step 4

switch(config-pmap-c)# pause no-drop

(Optional) Configures a no-drop class. If you do not specify this subcommand, the default policy is drop.

Note The operation for drop policy is simple tail drop, where arriving packets will be dropped if the queue increases to its allocated size

Step 5

switch(config-pmap-c)# mtu value

(Optional) Specifies the MTU value in bytes.

Step 6

switch(config-pmap-c) bandwidth percent percentage

(Optional) Specifies the guaranteed percentage of interface bandwidth allocated to this class.

Step 7

switch(config-pmap-c) priority

(Optional) Specifies that traffic in this class is mapped to a strict priority queue.

Step 8

switch(config-pmap-c) multicast-optimize

(Optional) Enables multicast optimization. Multicast traffic in this class will be served by all available multicast queues.

Note Only one class in a policy map can be configured for multicast optimization.

Note The switch distributes all the policy map configuration values to the attached network adapters.

Note Policy maps can also be configured for interface service policies. However, different parameters are supported in these policy maps. See the “Configuring QoS on Interfaces” section.

switch(config)# class-map ethCoS4

switch(config-cmap)# match cos 4

switch(config-cmap)# exit

switch(config)# policy-map ethNoDrop

switch(config-pmap)# class ethCoS4

switch(config-pmap-c)# pause no-drop

Creating the System Service Policy

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# system qos

Enters system class configuration mode.

Step 3

switch(config-sys-qos)# service-policy name

Specifies the policy-map to use as the service policy for the system.

The following example sets a no-drop Ethernet policy map as the system class:

switch(config)# class-map ethCoS4

switch(config-cmap)# match cos 4

switch(config-cmap)# exit

switch(config)# policy-map ethNoDrop

switch(config-pmap)# class ethCoS4

switch(config-pmap-c)# pause no-drop

switch(config)# system qos

switch(config-system)# service-policy ethNoDrop

System Class Example

The second class-map command changes the match value of the default no-drop system class.

The policy-map command defines a QoS policy for each traffic class. The new Ethernet class is configured as a no-drop class, with an MTU of 2000 bytes. The pause no-drop command causes PFC to apply pause functionality for packets with IEEE 802.1p priority value 5.

The service-policy command sets the specified policy as the system class.

Enable Link Level Flow Control Example

The following example shows how to enable link level flow control and to add a new policy-map as a no-drop class.

Switch(config)# class-map type network-qos class-test

Switch(config-cmap-nq)# match qos-group 4

Switch(config)# policy-map type network-qos Jumbo

Switch(config-pmap-nq)# class type network-qos class-test

Switch(config-pmap-nq-c)# pause no-drop buffer-size 152000 pause-threshold 103360 resume-threshold 83520

Switch(config-pmap-nq-c)# mtu 9216

Switch(config)# system qos

Switch(config-sys-qos)# service-policy type network-qos Jumbo

See the Configuring IEEE 802.3x Link-Level Flow Control section for details on enabling the flow-control send/receive on the interfaces.

Enabling Jumbo MTU

To enable jumbo MTU for the whole switch, set the MTU to its maximum size (9216 bytes) in the policy map for the default Ethernet system class (class-default).

In the following example, the default Ethernet system class is configured to support the jumbo MTU:

switch(config)# policy-map jumbo

switch(config-pmap)# class class-default

switch(config-pmap-c)# mtu 9216

switch(config)# system qos

switch(config-system)# service-policy jumbo

Note The system jumbomtu command defines the maximum MTU size for the switch. However, jumbo MTU is only supported for system classes that have mtu configured.

Verifying Jumbo MTU

To verify that jumbo MTU is enabled, enter the show interface ethernet slot/port command for an Ethernet interface that carries traffic with jumbo MTU.

The following example shows how to display summary jumbo MTU information for Ethernet 2/1 (the relevant part of the output is shown in bold font):

switch# show interface ethernet 2/1

Ethernet2/1 is up

...

Rx

1547805598 Input Packets 1547805596 Unicast Packets 0 Multicast Packets

0 Broadcast Packets 1301767362 Jumbo Packets 33690 Storm Suppression Packets

7181776513802 Bytes

Tx

1186564478 Output Packets 7060 Multicast Packets

0 Broadcast Packets 997813205 Jumbo Packets

4813632103603 Bytes

...

The following example shows how to display detailed jumbo MTU information for Ethernet 2/1 (the relevant part of the output is shown in bold font):

switch# show interface ethernet 2/1 counters detailed

Rx Packets: 1547805598

Rx Unicast Packets: 1547805596

Rx Jumbo Packets: 1301767362

Rx Bytes: 7181776513802

Rx Storm Suppression: 33690

Rx Packets from 0 to 64 bytes: 169219

Rx Packets from 65 to 127 bytes: 10657133

Rx Packets from 128 to 255 bytes: 21644488

Rx Packets from 256 to 511 bytes: 43290596

Rx Packets from 512 to 1023 bytes: 86583071

Rx Packets from 1024 to 1518 bytes: 83693729

Rx Trunk Packets: 1547805596

Tx Packets: 1186564481

Tx Unicast Packets: 1005445334

Tx Multicast Packets: 7063

Tx Jumbo Packets: 997813205

Tx Bytes: 4813632103819

Tx Packets from 0 to 64 bytes: 137912

Tx Packets from 65 to 127 bytes: 8288443

Tx Packets from 128 to 255 bytes: 16596457

Tx Packets from 256 to 511 bytes: 33177999

Tx Packets from 512 to 1023 bytes: 66363944

Tx Packets from 1024 to 1518 bytes: 64186521

Tx Trunk Packets: 1005451729

Configuring QoS on Interfaces

QoS parameters that can be configured on Ethernet and port channel interfaces are described in the following topics:

- Configuring Untagged CoS

- Configuring Ingress Policies

- Configuring Egress Policies

Configuring Untagged CoS

Any incoming packet not tagged with an 802.1p CoS value is assigned the default untagged CoS value of zero (which maps to the default Ethernet drop system class). You can override the default untagged CoS value for an Ethernet interface or port channel.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface {ethernet slot/port|port-channel channel-number }

Enters configuration mode for the specified interface or port channel.

Step 3

switch(config-if)# untagged cos cos-value

Configures the untagged CoS value.

Configuring Ingress Policies

An ingress policy is a service policy applied to incoming traffic on an Ethernet interface. The ingress policy is applied in the adapter to all outgoing traffic that matches the specified class. When you configure an ingress policy on an interface or port channel, the switch sends the configuration data to the adapter.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# class-map class-name

Creates a class for the ingress policy.

Step 3

switch(config)# policy-map policy1-name

Creates a policy map to specify the QoS parameters for the ingress policy.

Step 4

switch(config-pmap)# class class-name

Associates the ingress class with this policy and enters configuration mode for the class.

Step 5

switch(config-pmap-c) bandwidth percent percentage

(Optional) Specifies the guaranteed percentage of bandwidth allocated to incoming traffic of this class.

Step 6

switch(config-pmap-c) priority

(Optional) Specifies that ingress traffic in this class is mapped to a strict priority queue.

Step 7

switch(config)# interface interface {ethernet slot/port|port-channel channel-number }

Enters configuration mode for the specified interface.

Note service policy on a port channel overrides any service policy configuration on individual member interfaces.

Step 8

switch(config-if)# service-policy input policy-name

Applies the policy map to the interface.

The following example shows that the system class best-effort-drop-class is guaranteed 20 percent of the bandwidth on interface eth1/1:

switch(config)# class-map best-effort-drop-class

switch(config-cmap)# match cos 5

switch(config)# policy-map policy1

switch(config-pmap)# class best-effort-drop-class

switch(config-pmap-c)# bandwidth percent 20

switch(config)# int eth1/1

switch(config-if)# service-policy input policy1

Configuring Egress Policies

An egress policy is a service policy applied to the outgoing traffic on an Ethernet interface. You can configure an egress policy to guarantee the bandwidth for the specified traffic class or to configure the egress queues.

To configure an egress policy, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# class-map class-name

Defines a class name for the egress policy.

Step 3

switch(config)# policy-map policy1-name

Creates a policy map to specify the QoS parameters for the egress policy.

Step 4

switch(config-pmap)# class class-name

Associates the egress class with this policy and enters configuration mode for the class.

Step 5

switch(config-pmap-c) bandwidth percent percentage

Specifies the guaranteed percentage of bandwidth allocated to this class.

Step 6

switch(config-pmap-c) priority

Specifies that egress traffic in this class is mapped to a strict priority queue.

Step 7

switch(config)# interface {ethernet slot/port|port-channel channel-number }

Enters configuration mode for the specified interface.

Note service policy on a port channel overrides any service policy configuration on individual member interfaces.

Step 8

switch(config-if)# service-policy output policy-name

Applies the policy map to the interface.

The following example shows that the system class best-effort drop class is guaranteed 20 percent of the bandwidth on interface eth1/1:

switch(config)# class-map best-effort-drop-class

switch(config-cmap)# match cos 5

switch(config)# policy-map policy1-egress

switch(config-pmap)# class best-effort-drop-class

switch(config-pmap-c)# bandwidth percent 20

switch(config)# int eth1/1

switch(config-if)# service-policy output policy1-egress

Configuring Fibre Channel Interfaces

This chapter describes interface configuration for Fibre Channel interfaces and virtual Fibre Channel interfaces. This chapter includes the following sections:

- Information About Fibre Channel Interfaces

- Configuring Fibre Channel Interfaces

- Configuring Global Attributes for Fibre Channel Interfaces

- Verifying Fibre Channel Interfaces

- Default Settings

Information About Fibre Channel Interfaces

This section describes Fibre Channel interfaces and virtual Fibre Channel interfaces. This section includes the following topics:

- Licensing Requirements

- Physical Fibre Channel Interfaces

- Virtual Fibre Channel Interfaces

- Interface Modes

- Interface States

- Buffer-to-Buffer Credits

Licensing Requirements

On Cisco Nexus 5000 Series switches, Fibre Channel capability is included in the Storage Protocol Services license.

Ensure that you have the correct license installed (N5010SS or N5020SS) before using Fibre Channel interfaces and capabilities.

Note You can configure virtual Fibre Channel interfaces without a Storage Protocol Services license, but these interfaces will not become operational until the license is activated.

Physical Fibre Channel Interfaces

Cisco Nexus 5000 Series switches provide up to eight physical Fibre Channel uplinks. The Fibre Channel interfaces are supported on optional expansion modules. The Fibre Channel plus Ethernet expansion module contains four Fibre Channel interfaces.

Each Fibre Channel port can be used as a downlink (connected to a server) or as an uplink (connected to the data center SAN network). The Fibre Channel interfaces support the following modes: F, NP, E, TE, and SD.

Virtual Fibre Channel Interfaces

Fibre Channel over Ethernet (FCoE) encapsulation allows a physical Ethernet cable to simultaneously carry Fibre Channel and Ethernet traffic. In Cisco Nexus 5000 Series switches, an FCoE-capable physical Ethernet interface can carry traffic for one virtual Fibre Channel interface.

Native Fibre Channel and virtual Fibre Channel interfaces are configured using the same CLI commands. Virtual Fibre Channel interfaces support only F mode, and offer a subset of the features that are supported on native Fibre Channel interfaces.

The following capabilities are not supported for virtual Fibre Channel interfaces:

- SAN port channels.

- VSAN trunking. The virtual Fibre Channel is associated with one VSAN.

- The SPAN destination cannot be a virtual Fibre Channel interface.

- Buffer-to-buffer credits.

- Exchange link parameters (ELP), or Fabric Shortest Path First (FSPF) protocol.

- Configuration of physical attributes (speed, rate, mode, transmitter information, MTU size).

- Port tracking.

Interface Modes

Each physical Fibre Channel interface in a switch may operate in one of several port modes: E mode, TE mode, F mode, and SD mode (see Figure 1-1). A physical Fibre Channel interface can be configured as an E port, an F port, or an SD port. Interfaces may also be configured in Auto mode; the port type is determined during interface initialization.

In NPV mode, Fibre Channel interfaces may operate in NP mode, F mode or SD mode. For additional information about NPV mode, see Chapter1, “Configuring N Port Virtualization”

Virtual Fibre Channel interfaces can only be configured in F mode.

Figure 1-1 Switch Port Modes

Note Interfaces are automatically assigned VSAN 1 by default. See Chapter1, “Configuring and Managing VSANs”

Each interface has an associated administrative configuration and an operational status:

- The administrative configuration does not change unless you modify it. This configuration has various attributes that you can configure in administrative mode.

- The operational status represents the current status of a specified attribute such as the interface speed. This status cannot be changed and is read-only. Some values may not be valid when the interface is down (for example, the operational speed).

The following sections provide a brief description of each interface mode:

- E Port

- F Port

- NP Port

- TE Port

- SD Port

- Auto Mode

E Port

In expansion port (E port) mode, an interface functions as a fabric expansion port. This port may be connected to another E port to create an Inter-Switch Link (ISL) between two switches. E ports carry frames between switches for configuration and fabric management. They serve as a conduit between switches for frames destined to remote N ports. E ports support class 3 and class F service.

An E port connected to another switch may also be configured to form a SAN port channel (see Chapter 1, “Configuring SAN Port Channels”).

F Port

In fabric port (F port) mode, an interface functions as a fabric port. This port may be connected to a peripheral device (host or disk) operating as an N port. An F port can be attached to only one N port. F ports support class 3 service.

NP Port

When the switch is operating in NPV mode, the interfaces that connect the switch to the core network switch are configured as NP ports. NP ports operate like N ports that function as proxies for multiple physical N ports.

For more details about NP ports and NPV, see Chapter1, “Configuring N Port Virtualization”

TE Port

In trunking E port (TE port) mode, an interface functions as a trunking expansion port. It may be connected to another TE port to create an extended ISL (EISL) between two switches. TE ports connect to another Cisco Nexus 5000 Series switch or a Cisco MDS 9000 Family switch. They expand the functionality of E ports to support the following:

- VSAN trunking

- Fibre Channel trace (fctrace) feature

In TE port mode, all frames are transmitted in EISL frame format, which contains VSAN information. Interconnected switches use the VSAN ID to multiplex traffic from one or more VSANs across the same physical link. This feature is referred to as VSAN trunking in the Cisco Nexus 5000 Series (see Chapter 1, “Configuring VSAN Trunking”). TE ports support class 3 and class F service.

SD Port

In SPAN destination port (SD port) mode, an interface functions as a switched port analyzer (SPAN). The SPAN feature monitors network traffic that passes though a Fibre Channel interface. This monitoring is done using a standard Fibre Channel analyzer (or a similar switch probe) that is attached to an SD port. SD ports do not receive frames, instead they transmit a copy of the source traffic. The SPAN feature is nonintrusive and does not affect switching of network traffic for any SPAN source ports.

Auto Mode

Interfaces configured in auto mode can operate in one of the following modes: F port, E port, or TE port. The port mode is determined during interface initialization. For example, if the interface is connected to a node (host or disk), it operates in F port mode. If the interface is attached to a third-party switch, it operates in E port mode. If the interface is attached to another switch in the Cisco Nexus 5000 Series or Cisco MDS 9000 Family, it may become operational in TE port mode (see Chapter 1, “Configuring VSAN Trunking”).

SD ports are not determined during initialization and are administratively configured.

Interface States

The interface state depends on the administrative configuration of the interface and the dynamic state of the physical link. The following sections describe the states and configuration that influence the state:

- Administrative States

- Operational States

- Reason Codes

Administrative States

The administrative state refers to the administrative configuration of the interface. Table 1-1 describes the administrative states.

Table 1-1 Administrative States

Administrative State

Description

Up

Interface is enabled.

Down

Interface is disabled. If you administratively disable an interface by shutting down that interface, the physical link layer state change is ignored.

Operational States

The operational state indicates the current operational state of the interface. Table 1-2 describes the operational states.

Table 1-2 Operational States

Operational State

Description

Up

Interface is transmitting or receiving traffic as desired. To be in this state, an interface must be administratively up, the interface link layer state must be up, and the interface initialization must be completed.

Down

Interface cannot transmit or receive (data) traffic.

Trunking

Interface is operational in TE mode.

Reason Codes

Reason codes are dependent on the operational state of the interface. Table 1-3 describes the reason codes for operational states.

Table 1-3 Reason Codes for Interface States

Administrative Configuration

Operational Status

Reason Code

Up

Up

None.

Down

Down

Administratively down. If you administratively configure an interface as down, you disable the interface. No traffic is received or transmitted.

Up

Down

See Table 1-4.

Note Only some of the reason codes are listed in Table 1-4.

Table 1-4 Reason Codes for Nonoperational States

Reason Code (long version)

Description

Applicable Modes

Link failure or not connected

The physical layer link is not operational.

All

SFP not present

The small form-factor pluggable (SFP) hardware is not plugged in.

The physical layer link is operational and the protocol initialization is in progress.

All

Reconfigure fabric in progress

The fabric is currently being reconfigured.

Offline

The switch software waits for the specified R_A_TOV time before retrying initialization.

Inactive

The interface VSAN is deleted or is in a suspended state.

To make the interface operational, assign that port to a configured and active VSAN.

Hardware failure

A hardware failure is detected.

Error disabled

Error conditions require administrative attention. Interfaces may be error-disabled for various reasons. For example:

- Configuration failure.

- Incompatible buffer-to-buffer credit configuration.

To make the interface operational, you must first fix the error conditions causing this state and then administratively shut down or enable the interface.

Isolation because limit of active port channels is exceeded.

The interface is isolated because the switch is already configured with the maximum number of active SAN port channels.

Isolation due to ELP failure

The port negotiation failed.

Only E ports and TE ports

Isolation due to ESC failure

The port negotiation failed.

Isolation due to domain overlap

The Fibre Channel domains (fcdomain) overlap.

Isolation due to domain ID assignment failure

The assigned domain ID is not valid.

Isolation due to the other side of the link E port isolated

The E port at the other end of the link is isolated.

Isolation due to invalid fabric reconfiguration

The port is isolated due to fabric reconfiguration.

Isolation due to domain manager disabled

The fcdomain feature is disabled.

Isolation due to zone merge failure

The zone merge operation failed.

Isolation due to VSAN mismatch

The VSANs at both ends of an ISL are different.

port channel administratively down

The interfaces belonging to the SAN port channel are down.

Only SAN port channel interfaces

Suspended due to incompatible speed

The interfaces belonging to the SAN port channel have incompatible speeds.

Suspended due to incompatible mode

The interfaces belonging to the SAN port channel have incompatible modes.

Suspended due to incompatible remote switch WWN

An improper connection is detected. All interfaces in a SAN port channel must be connected to the same pair of switches.

Bound physical interface down

The Ethernet interface bound to a virtual Fibre Channel interface is not operational.

Only virtual Fibre Channel interfaces

STP not forwarding in FCoE mapped VLAN

The Ethernet interface bound to a virtual Fibre Channel interface is not in an STP forwarding state for the VLAN associated with the virtual Fibre Channel interface

Only virtual Fibre Channel interfaces

Buffer-to-Buffer Credits

Buffer-to-buffer credits (BB_credits) are a flow-control mechanism to ensure that Fibre Channel interfaces do not drop frames. BB_credits are negotiated on a per-hop basis.

In Cisco Nexus 5000 Series switches, the BB_credit mechanism is used on Fibre Channel interfaces but not on virtual Fibre Channel interfaces. Virtual Fibre Channel interfaces provide flow control based on capabilities of the underlying physical Ethernet interface.

The receive BB_credit value (fcrxbbcredit) may be configured for each Fibre Channel interface. In most cases, you do not need to modify the default configuration.

Note The receive BB_credit values depend on the port mode. For physical Fibre Channel interfaces, the default value is 16 for F mode and E mode interfaces. This value can be changed as required. The maximum value is 64.

Note For virtual Fibre Channel interfaces, BB_credits are not used.

Configuring Fibre Channel Interfaces

This section describes how to configure Fibre Channel interfaces, and includes the following topics:

- Configuring a Fibre Channel Interface

- Setting the Interface Administrative State

- Configuring Interface Modes

- Configuring the Interface Description

- Configuring Port Speeds

- Configuring SD Port Frame Encapsulation

- Configuring Receive Data Field Size

- Understanding Bit Error Thresholds

- Configuring Buffer-to-Buffer Credits

Configuring a Fibre Channel Interface

To configure a Fibre Channel interface, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port}|{vfc vfc-id}

switch(config-if)#

Selects a Fibre Channel interface and enters interface configuration mode.

Note When a Fibre Channel interface is configured, it is automatically assigned a unique world wide name (WWN). If the interface’s operational state is up, it is also assigned a Fibre Channel ID (FC ID).

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port - port [ , fc slot/port - port ]

or

switch(config)# interface vfc vfc-id - vfc-id [, vfc vfc-id - vfc-id ]

Setting the Interface Administrative State

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port}|{vfc vfc-id}

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# shutdown

Gracefully shuts down the interface and administratively disables traffic flow (default).

To enable traffic flow, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port}|{vfc vfc-id}

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# no shutdown

Enables traffic flow to administratively allow traffic when the no prefix is used (provided the operational state is up).

A virtual Fibre Channel interface becomes operational if the bound Ethernet interface is operational and its STP port state is active.

Configuring Interface Modes

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port}|{vfc vfc-id}

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport mode F

For a virtual Fibre Channel, only the F port mode is supported.

switch(config-if)# switchport mode E | F | SD | auto

For a Fibre Channel interface, you can set the mode to E, F, or SD port mode. Set the mode to auto to auto-negotiate an E, F, TE port mode (not SD port mode) of operation.

Note SD ports cannot be configured automatically. They must be administratively configured.

Configuring the Interface Description

Interface descriptions should help you identify the traffic or use for that interface. The interface description can be any alphanumeric string.

To configure a description for an interface, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port}|{vfc vfc-id}

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport description cisco-HBA2

Configures the description of the interface. The string can be up to 80 characters long.

switch(config-if)# no switchport description

Clears the description of the interface.

Configuring Port Speeds

Port speed can be configured on a physical Fibre Channel interface (but not on a virtual Fibre Channel interface). By default, the port speed for an interface is automatically calculated by the switch.

Caution Changing the interface speed is a disruptive operation.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

Selects the specified interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport speed 1000

Configures the port speed of the interface to 1000 Mbps.

The number indicates the speed in megabits per second (Mbps). You can set the speed to 1000 (for 1-Gbps interfaces), 2000 (for 2-Gbps interfaces), 4000 (for 4-Gbps interfaces), or auto (default).

switch(config-if)# no switchport speed

Reverts the factory default (auto) administrative speed of the interface.

Autosensing

Autosensing speed is enabled on all 4-Gbps interfaces by default. This configuration enables the interfaces to operate at speeds of 1 Gbps, 2 Gbps, or 4 Gbps on the 4-Gbps ports. When autosensing is enabled for an interface operating in dedicated rate mode, 4-Gbps of bandwidth is reserved, even if the port negotiates at an operating speed of 1-Gbps or 2-Gbps.

Configuring SD Port Frame Encapsulation

The switchport encap eisl command only applies to SD port interfaces. This command determines the frame format for all frames transmitted by the interface in SD port mode. If the encapsulation is set to EISL, all outgoing frames are transmitted in the EISL frame format, for all SPAN sources.

The switchport encap eisl command is disabled by default. If you enable encapsulation, all outgoing frames are encapsulated, and you will see a new line (Encapsulation is eisl) in the show interface SD_port_interface command output.

Configuring Receive Data Field Size

You can configure the receive data field size for native Fibre Channel interfaces (but not for virtual Fibre Channel interfaces). If the default data field size is 2112 bytes, the frame length will be 2148 bytes.

To configure the receive data field size, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport fcrxbufsize 2000

Reduces the data field size for the selected interface to 2000 bytes. The default is 2112 bytes and the range is from 256 to 2112 bytes.

Understanding Bit Error Thresholds

The bit error rate threshold is used by the switch to detect an increased error rate before performance degradation seriously affects traffic.

The bit errors can occur for the following reasons:

- Faulty or bad cable.

- Faulty or bad GBIC or SFP.

- GBIC or SFP is specified to operate at 1 Gbps but is used at 2 Gbps.

- GBIC or SFP is specified to operate at 2 Gbps but is used at 4 Gbps.

- Short haul cable is used for long haul or long haul cable is used for short haul.

- Momentary synchronization loss.

- Loose cable connection at one or both ends.

- Improper GBIC or SFP connection at one or both ends.

A bit error rate threshold is detected when 15 error bursts occur in a 5-minute period. By default, the switch disables the interface when the threshold is reached.

You can enter the shutdown/no shutdown command sequence to reenable the interface.

You can configure the switch to not disable an interface when the threshold is crossed.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport ignore bit-errors

Prevents the detection of bit error threshold events from disabling the interface.

switch(config-if)# no switchport ignore bit-errors

Prevents the detection of bit error threshold events from enabling the interface.

Note The switch generates a syslog message when bit error threshold events are detected, even if the interface is configured not to be disabled by bit-error threshold events.

Configuring Buffer-to-Buffer Credits

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

Selects a Fibre Channel interface and enters interface configuration mode.

Step 3

switch(config-if)# switchport fcrxbbcredit default

Applies the default operational value to the selected interface. The operational value depends on the port mode. The default values are assigned based on the port capabilities.

switch(config-if)# switchport fcrxbbcredit 5

Assigns a BB_credit of 5 to the selected interface. The range to assign BB_credits is between 1 and 64.

switch(config-if)# switchport fcrxbbcredit 5 mode E

Assigns this value if the port is operating in E or TE mode. The range to assign BB_credits is between 1 and 64.

switch(config-if)# switchport fcrxbbcredit 5 mode Fx

Assigns this value if the port is operating in F mode. The range to assign BB_credits is between 1 and 64.

Step 4

switch(config-if# do show int fc slot/port

Displays the receive and transmit BB_credit along with other pertinent interface information for this interface.

Note The BB_credit values are correct at the time the registers are read. They are useful to verify situations when the data traffic is slow.

Configuring Global Attributes for Fibre Channel Interfaces

This section describes configuration for global attributes that apply to all Fibre Channel interfaces on the switch. This section includes the following topics:

- Configuring Switch Port Attribute Default Values

- About N Port Identifier Virtualization

- Enabling N Port Identifier Virtualization

Configuring Switch Port Attribute Default Values

You can configure attribute default values for various switch port attributes. These attributes will be applied globally to all future switch port configurations, even if you do not individually specify them at that time.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# no system default switchport shutdown san

Configures the default setting for administrative state of an interface as Up. (The factory default setting is Down).

Tip This command is applicable only to interfaces for which no user configuration exists for the administrative state.

switch(config)# system default switchport shutdown san

Configures the default setting for administrative state of an interface as Down. This is the factory default setting.

Tip This command is applicable only to interfaces for which no user configuration exists for the administrative state.

switch(config)# system default switchport trunk mode auto

Configures the default setting for administrative trunk mode state of an interface as Auto.

Note The default setting is trunk mode on.

About N Port Identifier Virtualization

N port identifier virtualization (NPIV) provides a means to assign multiple FC IDs to a single N port. This feature allows multiple applications on the N port to use different identifiers and allows access control, zoning, and port security to be implemented at the application level. Figure 1-2 shows an example application using NPIV.

Figure 1-2 NPIV Example

Enabling N Port Identifier Virtualization

You must globally enable NPIV for all VSANs on the switch to allow the NPIV-enabled applications to use multiple N port identifiers.

Note All of the N port identifiers are allocated in the same VSAN.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# npiv enable

Enables NPIV for all VSANs on the switch.

Step 3

switch(config)# no npiv enable

Disables (default) NPIV on the switch.

Verifying Fibre Channel Interfaces

The following topics describe the commands for displaying Fibre Channel interfaces:

- Verifying SFP Transmitter Types

- Verifying Interface Information

- Verifying BB_Credit Information

Verifying SFP Transmitter Types

The SPF transmitter type can be displayed for a physical Fibre Channel interface (but not for a virtual Fibre Channel).

The small form-factor pluggable (SFP) hardware transmitters are identified by their acronyms when displayed in the show interface brief command. If the related SFP has a Cisco-assigned extended ID, then the show interface and show interface brief commands display the ID instead of the transmitter type. The show interface transceiver command and the show interface fc slot/port transceiver command display both values for Cisco supported SFPs.

Verifying Interface Information

The show interface command displays interface configurations. If no arguments are provided, this command displays the information for all the configured interfaces in the switch.

You can also specify arguments (a range of interfaces or multiple, specified interfaces) to display interface information. You can specify a range of interfaces by entering a command with the following example format:

interface fc2/1 - 4 , fc3/2 - 3

The following example shows how to display all interfaces:

switch# show interface

fc3/1 is up

...

fc3/3 is up

...

Ethernet1/3 is up

...

mgmt0 is up

...

vethernet1/1 is up

...

vfc 1 is up

...

The following example shows how to display multiple specified interfaces:

switch# show interface fc3/1 , fc3/3

fc3/1 is up

...

fc3/3 is up

...

The following example shows how to display a specific interface:

switch# show interface vfc 1

vfc 1 is up

...

The following example shows how to display interface descriptions:

switch# show interface description

-------------------------------------------------------------------------------

Interface Description

-------------------------------------------------------------------------------

fc3/1 test intest

Ethernet1/1 --

vfc 1 --

...

The following example shows how to display all interfaces in brief:

switch# show interface brief

The following example shows how to display interface counters:

switch# show interface counters

The following example shows how to display transceiver information for a specific interface:

switch# show interface fc3/1 transceiver

Note The show interface transceiver command is only valid if the SFP is present.

The show running-configuration command displays the entire running configuration with information for all interfaces. The interfaces have multiple entries in the configuration files to ensure that the interface configuration commands execute in the correct order when the switch reloads. If you display the running configuration for a specific interface, all the configuration commands for that interface are grouped together.

The following example shows the interface display when showing the running configuration for all interfaces:

switch# show running configuration

...

interface fc3/5

switchport speed 2000

...

interface fc3/5

switchport mode E

...

interface fc3/5

channel-group 11 force

no shutdown

The following example shows the interface display when showing the running configuration for a specific interface:

switch# show running configuration fc3/5

interface fc3/5

switchport speed 2000

switchport mode E

channel-group 11 force

no shutdown

Verifying BB_Credit Information

Table 1-5 Default native Fibre Channel Interface Parameters

Parameters

Default

Interface mode

Auto

Interface speed

Auto

Administrative state

Shutdown (unless changed during initial setup)

Trunk mode

On (unless changed during initial setup)

Trunk-allowed VSANs

1 to 4093

Interface VSAN

Default VSAN (1)

Beacon mode

Off (disabled)

EISL encapsulation

Disabled

Data field size

2112 bytes

Table 1-5 lists the default settings for virtual Fibre Channel interface parameters.

Table 1-6 Default Virtual Fibre Channel Interface Parameters

Parameters

Default

Interface mode

Auto

Interface speed

n/a

Administrative state

Shutdown (unless changed during initial setup)

Trunk mode

n/a

Trunk-allowed VSANs

n/a

Interface VSAN

Default VSAN (1)

EISL encapsulation

n/a

Data field size

Configuring SPAN

The Switched Port Analyzer (SPAN) feature (sometimes called port mirroring or port monitoring) selects network traffic for analysis by a network analyzer. The network analyzer can be a Cisco SwitchProbe, a Fibre Channel Analyzer, or other Remote Monitoring (RMON) probes.

This chapter includes the following sections:

- SPAN Sources

- SPAN Destinations

- Configuring SPAN

SPAN Sources

SPAN sources refer to the interfaces from which traffic can be monitored. The Cisco Nexus 5000 Series switch supports Ethernet, Fibre Channel, virtual Fibre Channel, port channels, SAN port channels, VLANs, and VSANs as SPAN sources. With VLANs or VSANs, all supported interfaces in the specified VLAN or VSAN are included as SPAN sources. You can choose the SPAN traffic in the ingress direction, the egress direction, or both directions for Ethernet, Fibre Channel, and virtual Fibre Channel source interfaces:

- Ingress source (Rx)—Traffic entering the switch through this source port is copied to the SPAN destination port.

- Egress source (Tx)—Traffic exiting the switch through this source port is copied to the SPAN destination port.

Characteristics of Source Ports

A source port, also called a monitored port, is a switched interface that you monitor for network traffic analysis. The switch supports any number of ingress source ports (up to the maximum number of available ports on the switch) and any number of source VLANs or VSANs.

A source port has these characteristics:

- Can be of any port type: Ethernet, Fibre Channel, virtual Fibre Channel, port channel, SAN port channel, VLAN, and VSAN.

- Cannot be monitored in multiple SPAN sessions.

- Cannot be a destination port.

- Each source port can be configured with a direction (ingress, egress, or both) to monitor. For VLAN, VSAN, port channel, and SAN port channel sources, the monitored direction can only be ingress and applies to all physical ports in the group. The rx/tx option is not available for VLAN or VSAN SPAN sessions.

- Source ports can be in the same or different VLANs or VSANs.

- For VLAN or VSAN SPAN sources, all active ports in the source VLAN or VSAN are included as source ports.

- The switch supports a maximum of two egress SPAN source ports.

Note Consider a scenario in which an ERSPAN session and a local SPAN session is configured on a switch. Egress ports on both sessions are different. However, the ingress port on the local SPAN session is also receiving GRE-encapsulated traffic from the ERSPAN session. In such a scenario, the local SPAN session captures only the non-GRE-encapsulated traffic from the port that is defined as the source.

SPAN Destinations

Source SPAN

Dest SPAN

Ethernet

Ethernet

Fibre Channel

Fibre Channel

Fibre Channel

Ethernet (FCoE)

Virtual Fibre Channel

Fibre Channel

Virtual Fibre Channel

Ethernet (FCoE)

Characteristics of Destination Ports

Each local SPAN session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source ports, VLANs, or VSANs. A destination port has these characteristics:

- Can be any physical port, Ethernet, Ethernet (FCoE), or Fibre Channel, and virtual Fibre Channel ports cannot be destination ports.

- Cannot be a source port.

- Cannot be a port channel or SAN port channel group.

- Does not participate in spanning tree while the SPAN session is active.

- Is excluded from the source list and is not monitored if it belongs to a source VLAN of any SPAN session.

- Receives copies of sent and received traffic for all monitored source ports. If a destination port is oversubscribed, it can become congested. This congestion can affect traffic forwarding on one or more of the source ports.

Configuring SPAN

You can configure a SPAN session to duplicate packets from source ports to the specified destination ports on the switch. This section includes the following topics:

- Creating and Deleting a SPAN Session

- Configuring the Destination Port

- Configuring Source Ports

- Configuring Source Port Channels, VLANs, or VSANs

- Configuring the Description of a SPAN Session

- Suspending or Activating a SPAN Session

- Displaying SPAN Information

Creating and Deleting a SPAN Session

You create a SPAN session by assigning a session number using the monitor command. If the session already exists, any additional configuration is added to that session.

To create a SPAN session, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session session-number

Enters the monitor configuration mode. New session configuration is added to the existing session configuration.

The session-number can be from 1 to 18. You can configure up to 18 sessions; however you can have only 2 sessions active at a time.

When you configure more than two SPAN sessions, the first two sessions are active. During startup, the order of active sessions is reversed; the last two sessions are active. For example, if you configured ten sessions 1 to 10 where 1 and 2 are active, after a reboot, sessions 9 and 10 will be active. To enable deterministic behavior, explicitly suspend the sessions 3 to 10 with the monitor session session-number shut command.

The following example shows creating a SPAN session:

switch# configure terminal

switch(config)# monitor session 2

To ensure that you are working with a completely new session, you can delete the desired session number or all SPAN sessions.

To delete SPAN sessions, perform this task:

Command

Purpose

switch(config)# no monitor session {all | session-number}

Deletes the configuration of the specified SPAN session or all sessions.

Configuring the Destination Port

The SPAN destination port can only be a physical port on the switch. There are minor differences between the configuration of Ethernet and Fibre Channel destination ports as detailed in the following topics.

Configuring an Ethernet Destination Port

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# interface ethernet slot/port

Enters interface configuration mode for the specified Ethernet interface selected by the slot and port values.

Step 3

switch(config-if)# switchport monitor

Sets the interface to monitor mode. Priority flow control is disabled when the port is configured as a SPAN destination.

Step 4

switch(config-if)# exit

Reverts to global configuration mode.

Step 5

switch(config)# monitor session session-number

Enters the monitor configuration mode.

Step 6

switch(config-monitor)# destination interface ethernet slot/port

Configures the Ethernet destination port.

The following example shows configuring an Ethernet SPAN destination port:

switch# configure terminal

switch(config)# interface ethernet 1/3

switch(config-if)# switchport monitor

switch(config-if)# exit

switch(config)# monitor session 2

switch(config-monitor)# destination interface ethernet 1/3

Configuring Fibre Channel Destination Port

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# interface fc slot/port

Enters interface configuration mode for the specified Fibre Channel interface selected by the slot and port values.

Step 3

switch(config-if)# switchport mode SD

Sets the interface to SPAN destination (SD) mode.

Step 4

switch(config-if)# switchport speed 1000

Sets the interface speed to 1000. The auto speed option is not allowed.

Step 5

switch(config-if)# exit

Reverts to global configuration mode.

Step 6

switch(config)# monitor session session-number

Enters the monitor configuration mode.

Step 7

switch(config-monitor)# destination interface fc slot/port

Configures the Fibre Channel destination port.

The following example shows configuring an Ethernet SPAN destination port:

switch# configure terminal

switch(config)# interface fc 2/4

switch(config-if)# switchport mode SD

switch(config-if)# switchport speed 1000

switch(config-if)# exit

switch(config)# monitor session 2

switch(config-monitor)# destination interface fc 2/4

Configuring Source Ports

You can configure the source ports for a SPAN session. The source ports can be Ethernet, Fibre Channel, or virtual Fibre Channel ports.

To configure the source ports for a SPAN session, perform this task:

Command

Purpose

switch(config-monitor)# source interface type slot/port [rx | tx | both]

Configures sources and the traffic direction in which to duplicate packets. You can enter a range of Ethernet, Fibre Channel, or virtual Fibre Channel ports. You can specify the traffic direction to duplicate as ingress (rx), egress (tx), or both. By default, the direction is both.

The following example shows configuring an Ethernet SPAN source port:

switch# configure terminal

switch(config)# monitor session 2

switch(config-monitor)# source interface ethernet 1/16

The following example shows configuring a Fibre Channel SPAN source port:

...

switch(config-monitor)# source interface fc 2/1

The following example shows configuring a virtual Fibre Channel SPAN source port:

...

switch(config-monitor)# source interface vfc 129

Configuring Source Port Channels, VLANs, or VSANs

You can configure the source channels for a SPAN session. These ports can be port channels, SAN port channels, VLANs, and VSANs. The monitored direction can only be ingress and applies to all physical ports in the group.

To configure the source channels for a SPAN session, perform this task:

Command

Purpose

switch(config-monitor)# source {interface {port-channel | san-port-channel} channel-number rx | vlan vlan-range | vsan vsan-range }

Configures port channel, SAN port channel, VLAN, or VSAN sources. The monitored direction can only be ingress and applies to all physical ports in the group. For VLAN or VSAN sources, the monitored direction is implicit.

The following example shows configuring a port channel SPAN source:

switch# configure terminal

switch(config)# monitor session 2

switch(config-monitor)# source interface port-channel 1 rx

The following example shows configuring a SAN port channel SPAN source:

...

switch(config-monitor)# source interface san-port-channel 3 rx

The following example shows configuring a VLAN SPAN source:

...

switch(config-monitor)# source vlan 1

- The following example shows configuring a VSAN SPAN source:

...

switch(config-monitor)# source vsan 1

Configuring the Description of a SPAN Session

Command

Purpose

switch(config-monitor)# description description

Applies a descriptive name to the SPAN session.

The following example shows configuring a description of a SPAN session:

switch# configure terminal

switch(config)# monitor session 2

switch(config-monitor)# description monitoring ports fc2/2-fc2/4

Suspending or Activating a SPAN Session

Command

Purpose

switch(config)# no monitor session {all | session-number} shut

Opens the specified SPAN session or all sessions.

The following example shows suspending a SPAN session:

...

switch(config)# monitor session 3 shut

Command

Purpose

switch(config)# monitor session {all | session-number} shut

Suspends the specified SPAN session or all sessions.

Note The Cisco Nexus 5000 Series switch supports two active SPAN sessions. When you configure more than two SPAN sessions, the first two sessions are active. During startup, the order of active sessions is reversed; the last two sessions are active. For example, if you configured ten sessions 1 to 10 where 1 and 2 are active, after a reboot, sessions 9 and 10 will be active. To enable deterministic behavior, explicitly suspend the sessions 3 to 10 with the monitor session session-number shut command.

Displaying SPAN Information

Command

Purpose

switch# show monitor [session {all | session-number | range session-range} [brief]]

Displays the SPAN configuration.

This example shows how to display SPAN session information:

switch# show monitor

SESSION STATE REASON DESCRIPTION

------- ----------- ---------------------- --------------------------------

2 up The session is up

3 down Session suspended

4 down No hardware resource

This example shows how to display SPAN session details:

switch# show monitor session 2

session 2

---------------

type : local

state : up

source intf :

rx : fc3/1

tx : fc3/1

both : fc3/1

source VLANs :

rx :

source VSANs :

rx : 1

destination ports : Eth3/1

Preface

This preface describes the audience, organization, and conventions of the Cisco Nexus 5000 Series CLI Configuration Guide. It also provides information on how to obtain related documentation.

Audience

This guide is for experienced network administrators who are responsible for configuring and maintaining Cisco Nexus 5000 Series switches.

Organization

This guide is organized as follows:

Chapter

Title

Description

Chapter 1

Product Overview

Presents an overview of the Cisco Nexus 5000 Series switches.

Part 1

Configuration Fundamentals

Contains chapters on using the CLI and initial switch configuration.

Part 2

LAN Switching

Contains chapters on how to configure Ethernet interfaces, VLANs, STP, Port Channels, trunks, the MAC address table and IGMP snooping.

Part 3

Switch Security Features

Contains chapters on how to configure AAA, Radius, TACACS+, SSH/Telnet and ACLs.

Part 4

System Management

Contains chapters on how to configure CFS, RBAC, System Message Logging, Call Home, SNMP, RMON, network management interfaces, storm control and SPAN.

Part 5

Fibre Channel over Ethernet

Contains chapters on how to configure FCoE and virtual interfaces.

Part 6

Quality of Service

Contains chapters on how to configure QoS.

Part 7

SAN Switching

Contains chapters on how to configure Fibre Channel interfaces and Fibre Channel capabilities (such as NPV, SAN-Port Channels, zones, DDAS, FSPF and security features).

Part 8

Troubleshooting

Contains chapters on how to perform basic troubleshooting.

Document Conventions

Command descriptions use these conventions:

boldface font

Commands and keywords are in boldface.

italic font

Arguments for which you supply values are in italics.

[ ]

Elements in square brackets are optional.

[ x | y | z ]

Optional alternative keywords are grouped in brackets and separated by vertical bars.

Screen examples 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.

This document uses the following conventions:

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

Documentation for Cisco Cisco Nexus 5000 Series switches is available at the following URL:

http://www.cisco.com/en/US/products/ps9670/tsd_products_support_series_home.html

The following are related Cisco Nexus 5000 Series documents:

Cisco Nexus 5000 Series Release Notes

Cisco Nexus 5000 Series CLI Software Configuration Guide, Release 4.0

Cisco Nexus 5000 Series Fabric Manager Software Configuration Guide, Release 4.0

Cisco Nexus 5000 Series System Messages Reference

Cisco Nexus 5000 Series Command Reference, Release 4.0

Cisco Nexus 5000 Series Hardware Installation Guide, Release 4.0

Cisco Nexus 5000 Series MIBs Reference, Release 4.0

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.

Configuring Virtual Interfaces

This section describes the configuration of virtual interfaces on the Cisco Nexus 5000 Series switches. It includes the following sections:

- Information About Virtual Interfaces

- Guidelines and Limitations

- Configuring Virtual Interfaces

- Verifying Virtual Interface Information

Information About Virtual Interfaces

Cisco Nexus 5000 Series switches support Fibre Channel over Ethernet (FCoE), which allows Fibre Channel and Ethernet traffic to be carried on the same physical Ethernet connection between the switch and the servers. For additional information about FCoE, see Chapter1, “Configuring FCoE”

The Fibre Channel portion of FCoE is configured as a virtual Fibre Channel interface. Logical Fibre Channel features (such as interface mode) can be configured on virtual Fibre Channel interfaces.

Note Virtual interfaces are created with the administrative state set to down. You need to explicitly configure the administrative state to bring the virtual interface into operation.

Guidelines and Limitations

When configuring virtual interfaces, note the following guidelines and limitations:

- Each virtual Fibre Channel interface must be bound to an FCoE-enabled Ethernet interface. FCoE is supported on 10-Gigabit Ethernet interfaces.

- Each virtual Fibre Channel interface is associated with only one VSAN.

- Any VSAN with associated virtual Fibre Channel interfaces must be mapped to a dedicated FCOE-enabled VLAN.

- FCoE is not supported on private VLANs.

Configuring Virtual Interfaces

This section describes how to configure virtual interfaces, and it includes the following topics:

- Creating a Virtual Fibre Channel Interface

- Mapping VSANs to VLANs

- Deleting a Virtual Fibre Channel Interface

Creating a Virtual Fibre Channel Interface

The Ethernet interface that you bind the virtual Fibre Channel interface to must be configured as follows:

- It must be a trunk port (use the switchport mode trunk command)

- The FCoE VLAN that corresponds to virtual Fibre Channel’s VSAN must be in the allowed VLAN list

- FCoE VLAN must not be configured as the native VLAN of the trunk port.

- The Ethernet interface must be configured as portfast (use the spanning-tree port type edge trunk command)

Following the above configuration guidelines will ensure a smooth upgrade to a T11 Fibre Channel Initialization Protocol (FIP) based FCoE release in the future.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface vfc vfc-id

Creates a virtual Fibre Channel interface (if it does not already exist) and enters interface configuration mode.

Virtual Fibre Channel interface ID is in the range of 1 to 8192.

Step 3

switch(config-if)# bind interface ethernet slot/port

Binds the virtual Fibre Channel interface to the specified physical Ethernet interface.

Mapping VSANs to VLANs

To create a mapping between a VSAN and its associated VLAN, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# vlan vlan-id

Enters VLAN configuration mode. VLAN number is in the range of 1 to 4096.

Step 3

switch(config-vlan)# fcoe [vsan vsan-id]

Enables FCoE for the specified VLAN. By default, a mapping is created from this VLAN to the VSAN with the same number.

(Optional) Configures the mapping from this VLAN to the specified VSAN.

Step 4

switch(config-vlan)# exit

Exits VLAN configuration mode.

Step 5

switch(config)# vsan database

Enters VSAN configuration mode.

Step 6

switch(config-vsan)# vsan vsan-id interface vfc vfc-id

Configures the association between VSAN and virtual Fibre Channel interface.

The VSAN number must map to a VLAN on the physical Ethernet interface that is bound to the virtual Fibre Channel interface.

The following example shows how to configure the VLAN on a physical Ethernet address, create virtual Fibre Channel interface 4, bind vfc 4 to the physical Ethernet interface, enable associated VLAN 200, and map VLAN 200 to VSAN 2:

switch# configure terminal

switch(config)# interface ethernet 1/2

switch(config-if)# switchport mode trunk

switch(config-if)# switchport trunk allowed vlan 1,200

switch(config)# interface vfc 4

switch(config-if)# bind interface ethernet 1/2

switch(config-if)# exit

switch(config)# vlan 200

switch(config-vlan)# fcoe vsan 2

switch(config-vlan)# exit

switch(config)# vsan database

switch(config-vsan)# vsan 2 interface vfc 4

Deleting a Virtual Fibre Channel Interface

To delete a virtual Fibre Channel interface, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# no interface vfc vfc-id

Deletes a virtual Fibre Channel interface.

The following example shows how to delete a virtual Fibre Channel interface:

switch# configure terminal

switch(config)# no interface vfc 4

switch(config-if)# exit

Verifying Virtual Interface Information

Command

Purpose

switch# show interface vfc vfc-id

Displays the detailed configuration of the specified Fibre Channel interface.

switch# show interface brief

Displays the status of all interfaces.

The following example shows how to display information about a virtual Fibre Channel interface:

switch# show interface vfc 3

vfc3 is down

Bound interface is Ethernet3/2

Hardware is GigabitEthernet

Port WWN is 20:01:00:0d:ec:6d:81:3f

Admin port mode is F

snmp link state traps are enabled

Port vsan is 1

Beacon is turned unknown

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

0 frames input, 0 bytes

0 discards, 0 errors

0 frames output, 0 bytes

0 discards, 0 errors

The following example shows the status of all the interfaces on the switch (some output has been removed for brevity):

switch# show interface brief

-------------------------------------------------------------------------------

Interface Vsan Admin Admin Status SFP Oper Oper Port

Mode Trunk Mode Speed Channel

Mode (Gbps)

-------------------------------------------------------------------------------

fc3/1 1 auto on trunking swl TE 2 --

fc3/2 1 auto on sfpAbsent -- -- --

...

fc3/8 1 auto on sfpAbsent -- -- --

-------------------------------------------------------------------------------

Interface Status IP Address Speed MTU Port

Channel

-------------------------------------------------------------------------------

Ethernet1/1 hwFailure -- -- 1500 --

Ethernet1/2 hwFailure -- -- 1500 --

Ethernet1/3 up -- 10000 1500 --

...

Ethernet1/39 sfpIsAbsen -- -- 1500 --

Ethernet1/40 sfpIsAbsen -- -- 1500 --

-------------------------------------------------------------------------------

Interface Status IP Address Speed MTU

-------------------------------------------------------------------------------

mgmt0 up 172.16.24.41 100 1500

-------------------------------------------------------------------------------

-------------------------------------------------------------------------------

Interface Vsan Admin Admin Status SFP Oper Oper Port

Mode Trunk Mode Speed Channel

Mode (Gbps)

-------------------------------------------------------------------------------

vfc 1 1 F -- down -- -- --

Advanced Fibre Channel Features and Concepts

This chapter describes the advanced Fibre Channel features provided in Cisco Nexus 5000 Series switches. It includes the following sections:

- Fibre Channel Timeout Values

- World Wide Names

- FC ID Allocation for HBAs

- Switch Interoperability

- Default Settings

Fibre Channel Timeout Values

You can modify Fibre Channel protocol-related timer values for the switch by configuring the following timeout values (TOVs):

- Distributed services TOV (D_S_TOV)—The valid range is from 5,000 to 10,000 milliseconds. The default is 5,000 milliseconds.

- Error detect TOV (E_D_TOV)—The valid range is from 1,000 to 10,000 milliseconds. The default is 2,000 milliseconds. This value is matched with the other end during port initialization.

- Resource allocation TOV (R_A_TOV)—The valid range is from 5,000 to 10,000 milliseconds. The default is 10,000 milliseconds. This value is matched with the other end during port initialization.

Note The fabric stability TOV (F_S_TOV) constant cannot be configured.

This section includes the following topics:

- Timer Configuration Across All VSANs

- Timer Configuration Per-VSAN

- About fctimer Distribution

- Enabling or Disabling fctimer Distribution

- Committing fctimer Changes

- Discarding fctimer Changes

- Fabric Lock Override

- Database Merge Guidelines

- Verifying Configured fctimer Values

Timer Configuration Across All VSANs

You can modify Fibre Channel protocol related timer values for the switch.

Caution The D_S_TOV, E_D_TOV, and R_A_ TOV values cannot be globally changed unless all VSANs in the switch are suspended.

Note If a VSAN is not specified when you change the timer value, the changed value is applied to all VSANs in the switch.

switch# configure terminal

switch(config)

Enters configuration mode.

Step 2

switch(config)# fctimer R_A_TOV timeout

Configures the R_A_TOV timeout value for all VSANs. The units is milliseconds.

This type of configuration is not permitted unless all VSANs are suspended.

Timer Configuration Per-VSAN

You can also issue the fctimer for a specified VSAN to configure different TOV values for VSANs with special links such as Fibre Channel. You can configure different E_D_TOV, R_A_TOV, and D_S_TOV values for individual VSANs. Active VSANs are suspended and activated when their timer values are changed.

Note This configuration must be propagated to all switches in the fabric. Be sure to configure the same value in all switches in the fabric.

To configure per-VSAN Fibre Channel timers, perform this task:

:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)

Enters configuration mode.

Step 2

switch(config#)# fctimer D_S_TOV timeout vsan vsan-id

Configures the D_S_TOV timeout value (in milliseconds) for the specified VSAN. Suspends the VSAN temporarily. You have the option to end this command, if required.

The following example configures the timer value for VSAN 2:

switch(config#)# fctimer D_S_TOV 6000 vsan 2

Warning: The vsan will be temporarily suspended when updating the timer value This configuration would impact whole fabric. Do you want to continue? (y/n) y

Since this configuration is not propagated to other switches, please configure the same value in all the switches

About fctimer Distribution

You can enable per-VSAN fctimer fabric distribution for all Cisco SAN switches in the fabric. When you perform fctimer configurations, and distribution is enabled, that configuration is distributed to all the switches in the fabric.

You automatically acquire a fabric-wide lock when you enter the first configuration command after you enabled distribution in a switch. The fctimer application uses the effective and pending database model to store or commit the commands based on your configuration.

See “Using Cisco Fabric Services,” for more information on the CFS application.

Enabling or Disabling fctimer Distribution

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# fctimer distribute

Enables fctimer configuration distribution to all switches in the fabric. Acquires a fabric lock and stores all future configuration changes in the pending database.

switch(config)# no fctimer distribute

Disables (default) fctimer configuration distribution to all switches in the fabric.

Committing fctimer Changes

When you commit the fctimer configuration changes, the effective database is overwritten by the configuration changes in the pending database and all the switches in the fabric receive the same configuration. When you commit the fctimer configuration changes without implementing the session feature, the fctimer configurations are distributed to all the switches in the physical fabric.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# fctimer commit

Distributes the fctimer configuration changes to all switches in the fabric and releases the lock. Overwrites the effective database with the changes made to the pending database.

Discarding fctimer Changes

After making the configuration changes, you can choose to discard the changes by discarding the changes instead of committing them. In either case, the lock is released.

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# fctimer abort

Discards the fctimer configuration changes in the pending database and releases the fabric lock.

Fabric Lock Override

If you have performed a fctimer fabric task and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.

Tip The changes are only available in the volatile directory and are subject to being discarded if the switch is restarted.

To use administrative privileges and release a locked fctimer session, use the clear fctimer session command.

switch# clear fctimer session

Database Merge Guidelines

When merging two fabrics, follow these guidelines:

- Be aware of the following merge conditions:

– The merge protocol is not implemented for distribution of the fctimer values. You must manually merge the fctimer values when a fabric is merged.

– The per-VSAN fctimer configuration is distributed in the physical fabric.

– The fctimer configuration is only applied to those switches containing the VSAN with a modified fctimer value.

– The global fctimer values are not distributed.

- Do not configure global timer values when distribution is enabled.

Note The number of pending fctimer configuration operations cannot be more than 15. After 15 operations, you must commit or abort the pending configurations before performing any more operations.

See the “CFS Merge Support” section for additional information.

Verifying Configured fctimer Values

Use the show fctimer command to display the configured fctimer values. The following example displays the configured global TOVs:

switch# show fctimer

F_S_TOV D_S_TOV E_D_TOV R_A_TOV

----------------------------------------

5000 ms 5000 ms 2000 ms 10000 ms

Note The F_S_TOV constant, though not configured, is displayed in the output of the show fctimer command.

Table 1-1 Standardized NAA WWN Formats

NAA Address

NAA Type

WWN Format

IEEE 48-bit address

Type 1 = 0001b

000 0000 0000b

48-bit MAC address

IEEE extended

Type 2 = 0010b

Locally assigned

48-bit MAC address

IEEE registered

Type 5 = 0101b

IEEE company ID: 24 bits

VSID: 36 bits

Caution Changes to the world-wide names should be made by an administrator or individual who is completely familiar with switch operations.

This section includes the following topics:

- Verifying WWN Information

- Link Initialization WWN Usage

- Configuring a Secondary MAC Address

Verifying WWN Information

switch# show wwn switch

Switch WWN is 20:00:ac:16:5e:52:00:00

Link Initialization WWN Usage

Exchange Link Protocol (ELP) and Exchange Fabric Protocol (EFP) use WWNs during link initialization. ELPs and EFPs both use the VSAN WWN by default during link initialization. However, the ELP usage changes based on the peer switch’s usage:

- If the peer switch ELP uses the switch WWN, then the local switch also uses the switch WWN.

- If the peer switch ELP uses the VSAN WWN, then the local switch also uses the VSAN WWN.

Configuring a Secondary MAC Address

To allocate secondary MAC addresses, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# wwn secondary-mac wwn-id range value

Configures the secondary MAC address. This command cannot be undone.

The following example shows how to configure the secondary MAC address:

switch(config)# wwn secondary-mac 00:99:55:77:55:55 range 64

This command CANNOT be undone.

Please enter the BASE MAC ADDRESS again: 00:99:55:77:55:55

Please enter the mac address RANGE again: 64

From now on WWN allocation would be based on new MACs.

Are you sure? (yes/no) no

You entered: no. Secondary MAC NOT programmed

FC ID Allocation for HBAs

Fibre Channel standards require a unique FC ID to be allocated to an N port attached to an F port in any switch. To conserve the number of FC IDs used, Cisco Nexus 5000 Series switches use a special allocation scheme.

Some HBAs do not discover targets that have FC IDs with the same domain and area. The switch software maintains a list of tested company IDs that do not exhibit this behavior. These HBAs are allocated with single FC IDs. If the HBA can discover targets within the same domain and area, a full area is allocated.

To allow further scalability for switches with numerous ports, the switch software maintains a list of HBAs that can discover targets within the same domain and area. Each HBA is identified by its company ID (also known as Organizational Unique Identifier, or OUI) used in the pWWN during a fabric log in. A full area is allocated to the N ports with company IDs that are listed and for the others, a single FC ID is allocated. Regardless of the type (whole area or single) of FC ID allocated, the FC ID entries remain persistent.

This section includes the following topics:

- Default Company ID List

- Verifying the Company ID Configuration

Default Company ID List

All Cisco Nexus 5000 Series switches contain a default list of company IDs that require area allocation. Using the company ID reduces the number of configured persistent FC ID entries. You can configure or modify these entries using the CLI.

Caution Persistent entries take precedence over company ID configuration. If the HBA fails to discover a target, verify that the HBA and the target are connected to the same switch and have the same area in their FC IDs, then perform the following procedure:

1. Shut down the port connected to the HBA.

2. Clear the persistent FC ID entry.

3. Get the company ID from the port WWN.

4. Add the company ID to the list that requires area allocation.

5. Bring up the port.

The list of company IDs have the following characteristics:

- A persistent FC ID configuration always takes precedence over the list of company IDs. Even if the company ID is configured to receive an area, the persistent FC ID configuration results in the allocation of a single FC ID.

- New company IDs added to subsequent releases are automatically added to existing company IDs.

- The list of company IDs is saved as part of the running and saved configuration.

- The list of company IDs is used only when the fcinterop FC ID allocation scheme is in auto mode. By default, the interop FC ID allocation is set to auto, unless changed.

Tip We recommend that you set the fcinterop FC ID allocation scheme to auto and use the company ID list and persistent FC ID configuration to manipulate the FC ID device allocation.

Use the fcinterop FCID allocation auto command to change the FC ID allocation and the show running-config command to view the currently allocated mode.

- When you enter a write erase , the list inherits the default list of company IDs shipped with a relevant release.

To allocate company IDs, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# fcid-allocation area company-id value

Adds a new company ID to the default list.

switch(config)# no fcid-allocation area company-id value

switch(config)# fcid-allocation area company-id 0x003223

Verifying the Company ID Configuration

You can view the configured company IDs by entering the show fcid-allocation area command. Default entries are listed first and the user-added entries are listed next. Entries are listed even if they were part of the default list and you later removed them.

The following example displays the list of default and configured company IDs:

switch# show fcid-allocation area

FCID area allocation company id info:

00:50:2E <-------------------- Default entry

00:50:8B

00:60:B0

00:A0:B8

00:E0:69

00:30:AE + <------------------ User-added entry

00:32:23 +

00:E0:8B * <------------- Explicitly deleted entry (from the original default list)

Total company ids: 7

+ - Additional user configured company ids.

* - Explicitly deleted company ids from default list.

You can implicitly derive the default entries shipped with a specific release by combining the list of Company IDs displayed without any identification with the list of deleted entries.

You can also view or obtain the company IDs in a specific WWN by entering the show fcid-allocation company-id-from-wwn command. Some WWN formats do not support company IDs. In these cases, you many need to configure the FC ID persistent entry.

The following example displays the company ID for the specified WWN:

switch# show fcid-allocation company-id-from-wwn 20:00:00:05:30:00:21:60

Extracted Company ID: 0x000530

Switch Interoperability

Interoperability enables the products of multiple vendors to interwork with each other. Fibre Channel standards guide vendors towards common external Fibre Channel interfaces.

Not all vendors follow the standards in the same way, which results in the need for interoperability modes. This section briefly explains the basic concepts of these modes.

Each vendor has a regular mode and an equivalent interoperability mode, which specifically turns off advanced or proprietary features and provides the product with a standards-compliant implementation.

Note For more information on configuring interoperability for Cisco Nexus 5000 Series switches, see the Cisco MDS 9000 Family Switch-to-Switch Interoperability Configuration Guide.

This section includes the following topics:

- About Interop Mode

- Configuring Interop Mode 1

- Verifying Interoperating Status

About Interop Mode

Cisco NX-OS software supports the following four interop modes:

- Mode 1— Standards-based interop mode that requires all other vendors in the fabric to be in interop mode.

- Mode 2—Brocade native mode (Core PID 0).

- Mode 3—Brocade native mode (Core PID 1).

- Mode 4—McData native mode.

For information about configuring interop modes 2, 3, and 4, see the Cisco MDS 9000 Family Switch-to-Switch Interoperability Configuration Guide, available at the following location:

http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/interoperability/guide/intopgd.html

Table 1-2 Changes in Switch Operation When Interoperability Is Enabled

Switch Feature

Changes if Interoperability Is Enabled

Domain IDs

Some vendors cannot use the full range of 239 domains within a fabric.

Domain IDs are restricted to the range 97 to 127, to accommodate McData’s nominal restriction to this same range. Domain IDs can either be static or preferred, which operate as follows:

- Static: Cisco switches accept only one domain ID; if a switch does not get that domain ID it isolates itself from the fabric.

- Preferred: If the switch does not get its requested domain ID, it accepts any assigned domain ID.

Timers

All Fibre Channel timers must be the same on all switches as these values are exchanged by E ports when establishing an ISL. The timers are F_S_TOV, D_S_TOV, E_D_TOV, and R_A_TOV.

F_S_TOV

Verify that the Fabric Stability Time Out Value timers match exactly.

D_S_TOV

Verify that the Distributed Services Time Out Value timers match exactly.

E_D_TOV

Verify that the Error Detect Time Out Value timers match exactly.

R_A_TOV

Verify that the Resource Allocation Time Out Value timers match exactly.

Trunking

Trunking is not supported between two different vendor’s switches. This feature may be disabled on a per port or per switch basis.

Default zone

The default zone operation of permit (all nodes can see all other nodes) or deny (all nodes are isolated when not explicitly placed in a zone) may change.

Zoning attributes

Zones may be limited to the pWWN and other proprietary zoning methods (physical port number) may be eliminated.
command to save fabric-wide zoning configuration. This command does not have any effect on Cisco Nexus 5000 Series switches if they are part of the same fabric. You must explicitly save the configuration on each Cisco Nexus 5000 Series switch.

Zone propagation

Some vendors do not pass the full zone configuration to other switches, only the active zone set gets passed.

Verify that the active zone set or zone configuration has correctly propagated to the other switches in the fabric.

VSAN

Note Interop modes cannot be enabled on FICON-enabled VSANs.

TE ports and SAN port channel s

TE ports and SAN port channels cannot be used to connect Cisco switches to non-Cisco SAN switches. Only E ports can be used to connect to non-Cisco SAN switches. TE ports and SAN port channels can still be used to connect a Cisco switch to other Cisco SAN switches even when in interop mode.

FSPF

The routing of frames within the fabric is not changed by the introduction of interop mode. The switch continues to use src-id, dst-id, and ox-id to load balance across multiple ISL links.

Domain reconfiguration disruptive

This is a switch-wide impacting event. Brocade and McData require the entire switch to be placed in offline mode and/or rebooted when changing domain IDs.

Domain reconfiguration nondisruptive

This event is limited to the affected VSAN. Cisco Nexus 5000 Series switches have the capability to restart only the domain manager process for the affected VSAN and not the entire switch.

Name server

Verify that all vendors have the correct values in their respective name server database.

Configuring Interop Mode 1

The interop mode1 in Cisco Nexus 5000 Series switches can be enabled disruptively or nondisruptively.

Note Brocade’s msplmgmtdeactivate command must explicitly be run prior to connecting from a Brocade switch to either Cisco Nexus 5000 Series switches or to McData switches. This command uses Brocade proprietary frames to exchange platform information, which Cisco Nexus 5000 Series switches or McData switches do not understand. Rejecting these frames causes the common E ports to become isolated.

To configure interop mode 1 in any switch in the Cisco Nexus 5000 Series, perform this task:

Step 1 Place the VSAN of the E ports that connect to the OEM switch in interoperability mode.

switch# configuration terminal

switch(config)# vsan database

switch(config-vsan-db)# vsan 1 interop 1

switch(config-vsan-db)# exit

switch(config)#

Step 2 Assign a domain ID in the range of 97 (0x61) through 127 (0x7F).

Note This is an limitation imposed by the McData switches.

switch(config)# fcdomain domain 100 preferred vsan 1

In Cisco Nexus 5000 Series switches, the default is to request an ID from the principal switch. If the preferred option is used, Cisco Nexus 5000 Series switches request a specific ID, but still join the fabric if the principal switch assigns a different ID. If the static option is used, the Cisco Nexus 5000 Series switches do not join the fabric unless the principal switch agrees and assigns the requested ID.

Note When changing the domain ID, the FC IDs assigned to N ports also change.

Step 3 Change the Fibre Channel timers (if they have been changed from the system defaults).

Note The Cisco Nexus 5000 Series, Brocade, and McData FC Error Detect (ED_TOV) and Resource Allocation (RA_TOV) timers default to the same values. They can be changed if needed. The RA_TOV default is 10 seconds, and the ED_TOV default is 2 seconds. Per the FC-SW2 standard, these values must be the same on each switch within the fabric.

switch(config)# fctimer e_d_tov ?

<1000-100000> E_D_TOV in milliseconds(1000-100000)

switch(config)# fctimer r_a_tov ?

<5000-100000> R_A_TOV in milliseconds(5000-100000)

Step 4 When making changes to the domain, you may or may not need to restart the domain manager function for the altered VSAN.

- Force a fabric reconfiguration with the disruptive option.

switch(config)# fcdomain restart disruptive vsan 1

or

- Do not force a fabric reconfiguration.

switch(config# fcdomain restart vsan 1

Verifying Interoperating Status

This section highlights the commands used to verify if the fabric is up and running in interoperability mode.

To verify the resulting status of entering the interoperability command in any switch in the Cisco Nexus 5000 Series, perform this task:

Step 1 Verify the software version.

switch# show version

Cisco Storage Area Networking Operating System (SAN-OS) Software

TAC support: http://www.cisco.com/tac

Copyright (c) 2002-2007, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained herein are owned by

other third parties and are used and distributed under license.

Some parts of this software may be covered under the GNU Public

License or the GNU Lesser General Public License. A copy of

each such license is available at

http://www.gnu.org/licenses/gpl.html and

http://www.gnu.org/licenses/lgpl.html

Software

BIOS: version

kickstart: version 4.0(0) [build 4.0(0.308)] [gdb]

system: version 4.0(0) [build 4.0(0.308)] [gdb]

BIOS compile time:

kickstart image file is: bootflash:///nuova-or-kickstart-nsg.0.1.0.001.bin

kickstart compile time: 10/12/2020 25:00:00 [02/22/2008 13:05:46]

system image file is: bootflash:/nuova-or-system-nsg.0.1.0.001.bin

system compile time: 10/22/2007 14:00:00 [02/22/2008 14:19:45]

Hardware

cisco Nexus5020 Chassis ("40x10GE/Supervisor")

Intel(R) Celeron(R) M CPU with 2074100 kB of memory.

Processor Board ID FOX1009009B

bootflash: 987136 kB

switch kernel uptime is 0 days 20 hours 6 minute(s) 55 second(s)

Last reset

Reason: Unknown

System version:

Service:

Step 2 Verify if the interface states are as required by your configuration.

switch# show int brief

-------------------------------------------------------------------------------

Interface Vsan Admin Admin Status SFP Oper Oper Port

Mode Trunk Mode Speed Channel

Mode (Gbps)

-------------------------------------------------------------------------------

fc3/1 1 E on trunking swl TE 2 --

fc3/2 1 auto on sfpAbsent -- -- --

fc3/3 1 E on trunking swl TE 2 --

fc3/4 1 auto on sfpAbsent -- -- --

fc3/5 1 auto auto notConnected swl -- --

fc3/6 1 auto on sfpAbsent -- -- --

fc3/7 1 auto auto sfpAbsent -- -- --

fc3/8 1 auto auto sfpAbsent -- -- --

Step 3 Verify if you are running the desired configuration.

switch# show run

Building Configuration...

interface fc2/1

no shutdown

interface fc2/2

no shutdown

interface fc2/3

interface fc2/4

<snip>

interface mgmt0

ip address 6.1.1.96 255.255.255.0

switchport encap default

no shutdown

vsan database

vsan 1 interop

boot system bootflash:/nx5000-system-23e.bin

boot kickstart bootflash:/nx5000-kickstart-23e.bin

callhome

fcdomain domain 100 preferred vsan 1

ip route 6.1.1.0 255.255.255.0 6.1.1.1

ip routing

line console

databits 5

speed 110

logging linecard

ssh key rsa 512 force

ssh server enable

switchname MDS9509

username admin password 5 $1$Li8/fBYX$SNc72.xt4nTXpSnR9OUFB/ role network-admin

Step 4 Verify if the interoperability mode is active.

switch# show vsan 1

vsan 1 information

name:VSAN0001 state:active

interoperability mode:yes <-------------------- verify mode

loadbalancing:src-id/dst-id/oxid

operational state:up

Step 5 Verify the domain ID.

switch# show fcdomain vsan 1

The local switch is a Subordinated Switch.

Local switch run time information:

State: Stable

Local switch WWN: 20:01:00:05:30:00:51:1f

Running fabric name: 10:00:00:60:69:22:32:91

Running priority: 128

Current domain ID: 0x64(100) <---------------verify domain id

Local switch configuration information:

State: Enabled

Auto-reconfiguration: Disabled

Contiguous-allocation: Disabled

Configured fabric name: 41:6e:64:69:61:6d:6f:21

Configured priority: 128

Configured domain ID: 0x64(100) (preferred)

Principal switch run time information:

Running priority: 2

Interface Role RCF-reject

---------------- ------------- ------------

fc2/1 Downstream Disabled

fc2/2 Downstream Disabled

fc2/4 Upstream Disabled

---------------- ------------- ------------

Step 6 Verify the local principal switch status.

switch# show fcdomain domain-list vsan 1

Number of domains: 5

Domain ID WWN

--------- -----------------------

0x61(97) 10:00:00:60:69:50:0c:fe

0x62(98) 20:01:00:05:30:00:47:9f

0x63(99) 10:00:00:60:69:c0:0c:1d

0x64(100) 20:01:00:05:30:00:51:1f [Local]

0x65(101) 10:00:00:60:69:22:32:91 [Principal]

--------- -----------------------

Step 7 Verify the next hop and destination for the switch.

switch# show fspf internal route vsan 1

FSPF Unicast Routes

---------------------------

VSAN Number Dest Domain Route Cost Next hops

-----------------------------------------------

1 0x61(97) 500 fc2/2

1 0x62(98) 1000 fc2/1

fc2/2

1 0x63(99) 500 fc2/1

1 0x65(101) 1000 fc2/4

Step 8 Verify the name server information.

switch# show fcns data vsan 1

VSAN 1:

------------------------------------------------------------------

FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE

------------------------------------------------------------------

0x610400 N 10:00:00:00:c9:24:3d:90 (Emulex) scsi-fcp

0x6105dc NL 21:00:00:20:37:28:31:6d (Seagate) scsi-fcp

0x6105e0 NL 21:00:00:20:37:28:24:7b (Seagate) scsi-fcp

0x6105e1 NL 21:00:00:20:37:28:22:ea (Seagate) scsi-fcp

0x6105e2 NL 21:00:00:20:37:28:2e:65 (Seagate) scsi-fcp

0x6105e4 NL 21:00:00:20:37:28:26:0d (Seagate) scsi-fcp

0x630400 N 10:00:00:00:c9:24:3f:75 (Emulex) scsi-fcp

0x630500 N 50:06:01:60:88:02:90:cb scsi-fcp

0x6514e2 NL 21:00:00:20:37:a7:ca:b7 (Seagate) scsi-fcp

0x6514e4 NL 21:00:00:20:37:a7:c7:e0 (Seagate) scsi-fcp

0x6514e8 NL 21:00:00:20:37:a7:c7:df (Seagate) scsi-fcp

0x651500 N 10:00:00:e0:69:f0:43:9f (JNI)

Total number of entries = 12

Note The Cisco switch name server shows both local and remote entries, and does not time out the entries.

Default Settings

Table 1-3 Default Settings for Advanced Features

Parameters

Default

CIM server

Disabled

CIM server security protocol

HTTP

D_S_TOV

5,000 milliseconds

E_D_TOV

2,000 milliseconds

R_A_TOV

10,000 milliseconds

Timeout period to invoke fctrace

5 seconds

Number of frame sent by the fcping feature

5 frames

Remote capture connection protocol

TCP

Remote capture connection mode

Passive

Local capture frame limits

10 frames

FC ID allocation mode

Auto mode

Loop monitoring

Disabled

Interop mode

Distributing Device Alias Services

Switches in the Cisco Nexus 5000 Series support Distributed Device Alias Services (device aliases) on a fabric-wide basis.

This chapter includes the following sections:

- Information About Device Aliases

- Device Alias Databases

- About Legacy Zone Alias Configuration

- Database Merge Guidelines

- Verifying Device Alias Configuration

- Default Settings

Information About Device Aliases

When the port WWN (pWWN) of a device must be specified to configure features (for example, zoning, DPVM, or port security) in a Cisco Nexus 5000 Series switch, you must assign the correct device name each time you configure these features. An inaccurate device name may cause unexpected results. You can circumvent this problem if you define a user-friendly name for a pWWN and use this name in all the configuration commands as required. These user-friendly names are referred to as device aliases.

This section includes the following topics:

- Device Alias Features

- Device Alias Requirements

- Zone Aliases Versus Device Aliases

Device Alias Features

Device aliases have the following features:

- The device alias information is independent of the VSAN configuration.

- The device alias configuration and distribution is independent of the zone server and the zone server database.

- You can import legacy zone alias configurations without losing data.

- The device alias application uses the Cisco Fabric Services (CFS) infrastructure to enable efficient database management and distribution. Device aliases use the coordinated distribution mode and the fabric-wide distribution scope (see Chapter 1, “Using Cisco Fabric Services”).

- Basic and enhanced modes. See the “Device Alias Modes” section.

- Device aliases used to configure zones, IVR zones, or port security features are displayed automatically with their respective pWWNs in the show command output.

Device Alias Requirements

Device aliases have the following requirements:

- You can only assign device aliases to pWWNs.

- There must be a one-to-one relationship between the pWWN and the device alias that maps to it.

- A device alias name is restricted to 64 alphanumeric characters and may include one or more of the following characters:

– a to z and A to Z

– Device alias names must begin with an alphabetic character (a to z or A to Z).

– 1 to 9

– - (hyphen) and _ (underscore)

– $ (dollar sign) and ^ (up caret)

Zone Aliases Versus Device Aliases

Table 1-1 Comparison Between Zone Aliases and Device Aliases

Zone-Based Aliases

Device Aliases

Aliases are limited to the specified VSAN.

You can define device aliases without specifying the VSAN number. You can also use the same definition in one or more VSANs without any restrictions.

Zone aliases are part of the zoning configuration. The alias mapping cannot be used to configure other features.

Device aliases can be used with any feature that uses the pWWN.

You can use any zone member type to specify the end devices.

Only pWWNs are supported.

Configuration is contained within the zone server database and is not available to other features.

Device aliases are not restricted to zoning. Device alias configuration is available to the FCNS, zone, fcping, and traceroute applications.

Device Alias Databases

The device alias feature uses two databases to accept and implement device alias configurations.

- Effective database—The database currently used by the fabric.

- Pending database—Your subsequent device alias configuration changes are stored in the pending database.

If you modify the device alias configuration, you need to commit or discard the changes as the fabric remains locked during this period.

Device alias database changes are validated with the applications. If any of the applications cannot accept the device alias database changes, then those changes are rejected; this applies to device alias database changes resulting from either a commit or merge operation.

This section includes the following topics:

- Creating Device Aliases

- Device Alias Modes

- Changing Device Alias Mode Guidelines

- Configuring Device Alias Modes

- About Device Alias Distribution

- Locking the Fabric

- Committing Changes

- Discarding Changes

- Fabric Lock Override

- Disabling and Enabling Device Alias Distribution

Creating Device Aliases

To a create a device alias in the pending database, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# device-alias database

switch(config-device-alias-db)#

Enters the pending database configuration submode.

Step 3

switch(config-device-alias-db)# device-alias name device-name pwwn pwwn-id

Specifies a device name for the device that is identified by its pWWN. Starts writing to the pending database and simultaneously locks the fabric as this is the first-issued device alias configuration command.

switch(config-device-alias-db)# no device-alias name device-name

Removes the device name for the device that is identified by its pWWN.

switch(config-device-alias-db)# device-alias rename old-device-name new-device-name

Renames an existing device alias with a new name.

To display the device alias configuration, use the show device-alias name command:

switch# show device-alias name x

device-alias name x pwwn 21:01:00:e0:8b:2e:80:93

Device Alias Modes

You can specify that aliases operate in basic or enhanced modes.

When operating in basic mode, which is the default mode, the device alias is immediately expanded to a pWWN. In basic mode, when device aliases are changed to point to a new HBA, for example, that change is not reflected in the zone server. Users must remove the previous HBA’s pWWN, add the new HBA’s pWWN, and then reactivate the zoneset.

When operating in enhanced mode, applications accept a device alias name in its “native” format. Instead of expanding the device alias to a pWWN, the device alias name is stored in the configuration and distributed in its native device alias format. So applications such as zone server, PSM or DPVM can automatically keep track of the device alias membership changes and enforce them accordingly. The primary benefit of operating in enhanced mode is that you have a single point of change.

Whenever you change device alias modes, the change is distributed to other switches in the network only if device alias distribution is enabled or on. Otherwise, the mode change only takes place on the local switch.

Note Enhanced mode, or native device alias-based configurations are not accepted in interop mode VSANs. IVR zoneset activation will fail in interop mode VSANs if the corresponding zones have native device alias-based members.

Changing Device Alias Mode Guidelines

When changing device alias modes, follow these guidelines:

- If two fabrics running in different device alias modes are joined together, the device alias merge will fail. There is no automatic conversion to one mode or the other during the merge process. In this situation, you must to select one mode over the other.

- Before changing from enhanced to basic mode, you must first explicitly remove all native device alias-based configurations from both local and remote switches, or, replace all device alias-based configuration members with the corresponding pWWN.

- If you remove a device alias from the device alias database, all applications will automatically stop enforcing the corresponding device alias. If that corresponding device alias is part of an active zoneset, all the traffic to and from that pWWN is disrupted.

- Renaming the device alias not only changes the device alias name in the device alias database, but also replaces the corresponding device alias configuration in all the applications.

- When a new device alias is added to the device alias database, and the application configuration is present on that device alias, it automatically takes effect. For example, if the corresponding device alias is part of the active zoneset and the device is online, then zoning is enforced automatically. You do not have to reactivate the zoneset.

- If a device alias name is mapped to a new HBA’s pWWN, then the application’s enforcement changes accordingly. In this case, the zone server automatically enforces zoning based on the new HBA’s pWWN.

Configuring Device Alias Modes

To configure device aliases to operate in enhanced mode, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# device-alias mode enhanced

switch(config)#

switch(config)# no device-alias mode enhance

Assigns the device alias to operate in basic mode.

To view the current device alias mode setting, enter the show device-alias status command.

switch# show device-alias status

Fabric Distribution: Enabled

Database:- Device Aliases 0 Mode: Basic

Locked By:- User "admin" SWWN 20:00:00:0d:ec:30:90:40

Pending Database:- Device Aliases 0 Mode: Basic

About Device Alias Distribution

By default, device alias distribution is enabled. The device alias feature uses CFS to distribute the modifications to all switches in a fabric.

If device alias distribution is disabled, database changes are not distributed to the switches in the fabric. The same changes would have to be performed manually on all switches in the fabric to keep the device alias database up-to-date. Database changes immediately take effect, so there would not be any pending database and commit or abort operations either. If you have not committed the changes and you disable distribution, then a commit task will fail.

- No other user can make any configuration changes to this feature.

- A copy of the effective database is obtained and used as the pending database. Subsequent modifications are made to the pending database. The pending database remains in use until you commit the modifications to the pending database or discard ( abort ) the changes to the pending database.

Committing Changes

If you commit the changes made to the pending database, the following events occur:

1. The pending database content overwrites the effective database content.

2. The pending database is distributed to the switches in the fabric and the effective database on those switches is overwritten with the new changes.

3. The pending database is emptied of its contents.

4. The fabric lock is released for this feature.

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# device-alias commit

Commits the changes made to the currently active session.

Discarding Changes

If you discard the changes made to the pending database, the following events occur:

1. The effective database contents remain unaffected.

2. The pending database is emptied of its contents.

3. The fabric lock is released for this feature.

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# device-alias abort

Discards the currently active session.

To display the status of the discard operation, use the show device alias status command.

switch# show device-alias status

Fabric Distribution: Enabled

Database:- Device Aliases 24

Status of the last CFS operation issued from this switch:

==========================================================

Operation: Abort

Status: Success

Fabric Lock Override

You can use locking operations (clear, commit, abort) only when device alias distribution is enabled. If you have performed a device alias task and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.

Tip The changes are only available in the volatile directory and may be discarded if the switch is restarted.

switch# show device-alias status

Fabric Distribution: Enabled

Database:- Device Aliases 24

Status of the last CFS operation issued from this switch:

==========================================================

Operation: Clear Session <--------------------Lock released by administrator

Status: Success <---------------------------------Successful status of the operation

Disabling and Enabling Device Alias Distribution

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# no device-alias distribute

Disables the distribution.

switch(config)# device-alias distribute

Enables the distribution (default).

To display the status of device alias distribution, use the show device-alias status command. The following example shows the device alias display when distribution is enabled:

switch# show device-alias status

Fabric Distribution: Enabled <-------------------------------Distribution is enabled

Database:-Device Aliases 24

Locked By:-User “Test” SWWN 20:00:00:0c:cf:f4:02:83<-Lock holder’s user name and switch ID

Pending Database:- Device Aliases 24

Status of the last CFS operation issued from this switch:

==========================================================

Operation: Enable Fabric Distribution

Status: Success

The following example shows the device alias display when distribution is disabled:

switch# show device-alias status

Fabric Distribution: Disabled

Database:- Device Aliases 24

Status of the last CFS operation issued from this switch:

==========================================================

Operation: Disable Fabric Distribution

Status: Success

About Legacy Zone Alias Configuration

You can import legacy zone alias configurations to use this feature without losing data if they satisfy the following restrictions:

- Each zone alias has only one member.

- The member type is pWWN.

If any name or definition conflict exists, the zone aliases are not imported.

Tip Ensure that you copy any required zone aliases to the device alias database as required by your configuration.

When an import operation is complete, the modified alias database is distributed to all other switches in the physical fabric when you perform the commit operation. If you do not want to distribute the configuration to other switches in the fabric, you can perform the abort operation and the merge changes are completely discarded.

Importing a Zone Alias

To import the zone alias for a specific VSAN, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# device-alias import fcalias vsan vlan-id

Imports the fcalias information for the specified VSAN.

Database Merge Guidelines

When merging two device alias databases, follow these guidelines:

- Verify that two device aliases with different names are not mapped to the same pWWN.

- Verify that two identical pWWNs are not mapped to two different device aliases.

- Verify that the combined number of device aliases in both databases does not exceed 8K (8191 device aliases) in fabrics running Cisco MDS SAN-OS release 3.0 (x) and earlier, and 20K in fabrics running Cisco MDS SAN-OS release 3.1(x) and later.

If the combined number of device entries in both databases exceeds the supported configuration limit, then the merge will fail. For example, if database N has 6000 device aliases and database M has 2192 device aliases, and you are running SAN-OS 3.0(x) or earlier, then this merge operation will fail. Merge operations will also fail if there is a device alias mode mismatch.

For additional information, see the “CFS Merge Support” section.

Verifying Device Alias Configuration

Command

Purpose

switch# show zoneset [active]

Displays the device aliases in the zone set information.

switch# show device-alias database [pending | pending-diffs]

Displays the device alias database.

switch# show device-alias pwwn pwwn-id |name device-name [pending]

Displays the device alias information for the specified pwwn or alias.

switch# show flogi database [pending]

Displays device alias information the the flogi database.

switch# show fcns database [pending]

Displays device alias information the the fcns database.

The following example shows how to display device alias information in the zone set:

switch# show zoneset

zoneset name s1 vsan 1

zone name z1 vsan 1

pwwn 21:01:00:e0:8b:2e:80:93 [x] <---------------Device alias displayed for each pWWN.

pwwn 21:00:00:20:37:39:ab:5f [y]

zone name z2 vsan 1

pwwn 21:00:00:e0:8b:0b:66:56 [SampleName]

pwwn 21:00:00:20:37:39:ac:0d [z]

The following example shows how to display pending changes in the device alias database:

switch# show device-alias database pending

The following example shows how to display a specific pWWN in the device alias database:

switch# show device-alias pwwn 21:01:00:e0:8b:2e:80:93 pending

The following example shows how to display the difference between the pending and effective device alias databases:

switch# show device-alias database pending-diff

- device-alias name Doc pwwn 21:01:02:03:00:01:01:01

+ device-alias name SampleName pwwn 21:00:00:e0:8b:0b:66:56

Where available, device aliases are displayed regardless of a member being configured using a device-alias command or a zone-specific member pwwn command.

Default Settings

Table 1-2 Default Device Alias Parameters

Parameters

Default

Device alias distribution

Enabled.

Device alias mode

Basic.

Database in use

Effective database.

Database to accept changes

Pending database.

Device alias fabric lock state

Managing FLOGI, Name Server, FDMI, and RSCN Databases

This chapter describes the fabric login (FLOGI) database, the name server features, the Fabric-Device Management Interface (FDMI), and Registered State Change Notification (RSCN) information provided in Cisco Nexus 5000 Series switches. It includes the following sections:

- Information About Fabric Login

- Name Server Proxy

- FDMI

- Displaying FDMI

- RSCN

- Default Settings

Information About Fabric Login

In a Fibre Channel fabric, each host or disk requires an FC ID. Use the show flogi command to verify if a storage device is displayed in the fabric login (FLOGI) table as in the following examples. If the required device is displayed in the FLOGI table, the fabric login is successful. Examine the FLOGI database on a switch that is directly connected to the host HBA and connected ports.

switch# show flogi database interface vfc1/1

INTERFACE VSAN FCID PORT NAME NODE NAME

---------------------------------------------------------------------------

vfc1/1 1 0x870000 20:00:00:1b:21:06:58:bc 10:00:00:1b:21:06:58:bc

Total number of flogi = 1.

The following example shows how to verify the storage devices associated with VSAN 1:

switch# show flogi database vsan 1

Name Server Proxy

The name server functionality maintains a database containing the attributes for all hosts and storage devices in each VSAN. Name servers allow a database entry to be modified by a device that originally registered the information.

The proxy feature is useful when you need to modify (update or delete) the contents of a database entry that was previously registered by a different device.

This section includes the following topics:

- About Registering Name Server Proxies

- Registering Name Server Proxies

- About Rejecting Duplicate pWWNs

- Rejecting Duplicate pWWNs

- About Name Server Database Entries

- Displaying Name Server Database Entries

About Registering Name Server Proxies

All name server registration requests come from the same port whose parameter is registered or changed. If it does not, then the request is rejected.

This authorization enables WWNs to register specific parameters for another node.

Registering Name Server Proxies

To register the name server proxy, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# fcns proxy-port wwn-id vsan vsan-id

Configures a proxy port for the specified VSAN.

About Rejecting Duplicate pWWNs

You can prevent malicious or accidental log in using another device’s pWWN by enabling the reject-duplicate-pwwn option. If you disable this option, these pWWNs are allowed to log in to the fabric and replace the first device in the name server database.

Rejecting Duplicate pWWNs

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# fcns reject-duplicate-pwwn vsan vsan-id

Logs out devices when they log into the fabric if the pWWNs already exist.

switch(config)# no fcns reject-duplicate-pwwn vsan vsan-id

Overwrites the first device’s entry in the name server database with the new device having the same pWWN (default).

About Name Server Database Entries

The name server stores name entries for all hosts in the FCNS database. The name server permits an Nx port to register attributes during a PLOGI (to the name server) to obtain attributes of other hosts. These attributes are deregistered when the Nx port logs out either explicitly or implicitly.

In a multiswitch fabric configuration, the name server instances running on each switch shares information in a distributed database. One instance of the name server process runs on each switch.

Displaying Name Server Database Entries

The following example shows how to display the name server database for all VSANs:

switch# show fcns database

--------------------------------------------------------------------------

FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE

--------------------------------------------------------------------------

0x010000 N 50:06:0b:00:00:10:a7:80 scsi-fcp fc-gs

0x010001 N 10:00:00:05:30:00:24:63 (Cisco) ipfc

0x010002 N 50:06:04:82:c3:a0:98:52 (Company 1) scsi-fcp 250

0x010100 N 21:00:00:e0:8b:02:99:36 (Company A) scsi-fcp

0x020000 N 21:00:00:e0:8b:08:4b:20 (Company A)

0x020100 N 10:00:00:05:30:00:24:23 (Cisco) ipfc

0x020200 N 21:01:00:e0:8b:22:99:36 (Company A) scsi-fcp

The following example shows how to display the name server database and statistical information for a specified VSAN:

switch# show fcns database vsan 1

VSAN 1:

--------------------------------------------------------------------------

FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE

--------------------------------------------------------------------------

0x030001 N 10:00:00:05:30:00:25:a3 (Cisco) ipfc

0x030101 NL 10:00:00:00:77:99:60:2c (Interphase)

0x030200 N 10:00:00:49:c9:28:c7:01

0xec0001 NL 21:00:00:20:37:a6:be:14 (Seagate) scsi-fcp

Total number of entries = 4

The following example shows how to display the name server database details for all VSANs:

switch# show fcns database detail

------------------------

The following example shows how to display the name server database statistics for all VSANs:

switch# show fcns statistics

FDMI

Cisco Nexus 5000 Series switches provide support for the Fabric-Device Management Interface (FDMI) functionality, as described in the FC-GS-4 standard. FDMI enables management of devices such as Fibre Channel host bus adapters (HBAs) through in-band communications. This addition complements the existing Fibre Channel name server and management server functions.

Using the FDMI functionality, the switch software can extract the following management information about attached HBAs and host operating systems without installing proprietary host agents:

- Manufacturer, model, and serial number

- Node name and node symbolic name

- Hardware, driver, and firmware versions

- Host operating system (OS) name and version number

All FDMI entries are stored in persistent storage and are retrieved when the FDMI process is started.

Displaying FDMI

The following example shows how to display all HBA details for a specified VSAN:

switch# show fdmi database detail vsan 1

RSCN

The Registered State Change Notification (RSCN) is a Fibre Channel service that informs hosts about changes in the fabric. Hosts can receive this information by registering with the fabric controller (through SCR). These notifications provide a timely indication of one or more of the following events:

- Disks joining or leaving the fabric

- A name server registration change

- A new zone enforcement

- IP address change

- Any other similar event that affects the operation of the host

This section includes the following topics:

- About RSCN Information

- Displaying RSCN Information

- About the multi-pid Option

- Configuring the multi-pid Option

- Suppressing Domain Format SW-RSCNs

- Clearing RSCN Statistics

- Configuring the RSCN Timer

- Verifying the RSCN Timer Configuration

- RSCN Timer Configuration Distribution

About RSCN Information

A switch RSCN (SW-RSCN) is sent to registered hosts and to all reachable switches in the fabric.

Note The switch sends an RSCN to notify registered nodes that a change has occurred. It is up to the nodes to query the name server again to obtain the new information. The details of the changed information are not delivered by the switch in the RSCN sent to the nodes.

Displaying RSCN Information

About the multi-pid Option

If the RSCN multi-pid option is enabled, then RSCNs generated to the registered Nx ports may contain more than one affected port IDs. In this case, zoning rules are applied before putting the multiple affected port IDs together in a single RSCN. By enabling this option, you can reduce the number of RSCNs. For example, you have two disks (D1, D2) and a host (H) connected to switch 1. Host H is registered to receive RSCNs. D1, D2 and H belong to the same zone. If disks D1 and D2 are online at the same time, one of the following actions applies:

- The multi-pid option is disabled on switch 1— Two RSCNs are generated to host H: one for the disk D1 and another for disk D2.

- The multi-pid option is enabled on switch 1—A single RSCN is generated to host H, and the RSCN payload lists the affected port IDs (in this case, both D1 and D2).

Note Some Nx ports may not support multi-pid RSCN payloads. If so, disable the RSCN multi-pid option.

Configuring the multi-pid Option

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn multi-pid vsan vsan-id

Sends RSCNs in a multi-pid format for the specified VSAN.

Suppressing Domain Format SW-RSCNs

A domain format SW-RSCN is sent whenever the local switch name or the local switch management IP address changes. This SW-RSCN is sent to all other domains and switches over the ISLs. The remote switches can issue GMAL and GIELN commands to the switch that initiated the domain format SW-RSCN to determine what changed. Domain format SW-RSCNs can cause problems with some non-Cisco SAN switches. For additional information, see the Cisco MDS 9000 Family Switch-to-Switch Interoperability Configuration Guide, available at the following location:

http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/interoperability/guide/intopgd.html

To suppress the transmission of these SW-RSCNs over an ISL, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn suppress domain-swrscn vsan vsan-id

Suppresses transmission of domain format SW-RSCNs for the specified VSAN.

Note You cannot suppress transmission of port address or area address format RSCNs.

Clearing RSCN Statistics

You can clear the counters and later view the counters for a different set of events. For example, you can keep track of how many RSCNs or SW-RSCNs are generated on a particular event (such as ONLINE or OFFLINE events). You can use these statistics to monitor responses for each event in the VSAN.

The following example shows how to clear the RSCN statistics for the specified VSAN:

switch# clear rscn statistics vsan 1

After clearing the RSCN statistics, you can view the cleared counters by entering the show rscn statistics command:

switch# show rscn statistics vsan 1

Configuring the RSCN Timer

RSCN maintains a per VSAN event list queue, where the RSCN events are queued as they are generated. When the first RSCN event is queued, a per VSAN timer starts. Upon time-out, all the events are dequeued and coalesced RSCNs are sent to registered users. The default timer values minimize the number of coalesced RSCNs sent to registered users. Some deployments require smaller event timer values to track changes in the fabric.

Note The RSCN timer value must be the same on all switches in the VSAN. See the “RSCN Timer Configuration Distribution” section.

Note Before performing a downgrade, make sure that you revert the RCSN timer value in your network to the default value. Failure to do so will disable the links across your VSANs and other devices.

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn distribute

Enables RSCN timer configuration distribution.

Step 3

switch(config)# rscn event-tov timeout vsan vsan-id

Sets the event time-out value in milliseconds for the specified VSAN. The range is 0 to 2000 milliseconds. Setting a zero (0) value disables the timer.

switch(config)# no rscn event-tov timeout vsan vsan-id

Reverts to the default value (2000 milliseconds for Fibre Channel VSANs).

Step 4

switch(config)# rscn commit vsan vsan-id

Commits the RSCN timer configuration to be distributed to the switches in the specified VSAN.

In this example the event time-out value is set to 300 milliseconds for VSAN 12.

switch# rscn event-tov 300 vsan 12

Verifying the RSCN Timer Configuration

RSCN supports two modes, distributed and nondistributed. In distributed mode, RSCN uses CFS to distribute configuration to all switches in the fabric. In nondistributed mode, only the configuration commands on the local switch are affected.

Note All configuration commands are not distributed. Only the rscn event-tov tov vsan vsan command is distributed.

Note Only the RSCN timer configuration is distributed.

The RSCN timer is registered with CFS during initialization and switchover. For high availability, if the RSCN timer distribution crashes and restarts or a switchover occurs, it resumes normal functionality from the state prior to the crash or switchover.

This section includes the following topics:

- Enabling RSCN Timer Configuration Distribution

- Locking the Fabric

- Committing the RSCN Timer Configuration Changes

- Discarding the RSCN Timer Configuration Changes

- Clearing a Locked Session

- Displaying RSCN Configuration Distribution Information

Enabling RSCN Timer Configuration Distribution

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn distribute

Enables RSCN timer distribution.

switch(config)# no rscn distribute

Disables (default) RSCN timer distribution.

Locking the Fabric

The first action that modifies the database creates the pending database and locks the feature in the VSAN. Once you lock the fabric, the following situations apply:

- No other user can make any configuration changes to this feature.

- A copy of the configuration database becomes the pending database along with the first active change.

Committing the RSCN Timer Configuration Changes

If you commit the changes made to the active database, the configuration is committed to all the switches in the fabric. On a successful commit, the configuration change is applied throughout the fabric and the lock is released.

To commit RSCN timer configuration changes, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn commit vsan timeout

Commits the RSCN timer changes.

Discarding the RSCN Timer Configuration Changes

If you discard (abort) the changes made to the pending database, the configuration database remains unaffected and the lock is released.

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# rscn abort vsan timeout

Discards the RSCN timer changes and clears the pending configuration database.

Clearing a Locked Session

If you have changed the RSCN timer configuration and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.

Tip The pending database is only available in the volatile directory and are subject to being discarded if the switch is restarted.

switch# show cfs application name rscn

Enabled : Yes

Timeout : 5s

Merge Capable : Yes

Scope : Logical

Note A merge failure results when the RSCN timer values are different on the merging fabrics.

The following example shows how to display the set of configuration commands that would take effect when you commit the configuration:

Note The pending database includes both existing and modified configuration.

switch# show rscn pending

rscn event-tov 2000 ms vsan 1

rscn event-tov 2000 ms vsan 2

rscn event-tov 300 ms vsan 10

The following example shows how to display the difference between pending and active configurations:

switch# show rscn pending-diff vsan 10

- rscn event-tov 2000 ms vsan 10

+ rscn event-tov 300 ms vsan 10

Default Settings

Table 1-1 Default RSCN Settings

Parameters

Default

RSCN timer value

2000 milliseconds for Fibre Channel VSANs

RSCN timer configuration distribution

Configuring the Switch

This chapter describes basic switch configuration functions. This chapter includes the following sections:

- Image Files on the Switch

- Upgrading the Switch

- Downgrading from a Higher Release

- Initial Configuration

- Accessing the Switch

- Additional Switch Configuration

- NTP Configuration

- Management Interface Configuration

- Managing the Switch Configuration

- Using Switch File Systems

Image Files on the Switch

The Cisco Nexus 5000 Series switches have the following images:

- BIOS and loader images combined in one file

- Kickstart image

- System image that includes a BIOS image that can be upgraded

The switch has flash memory that consists of two separate flash parts:

- A 2 MB flash part holds two BIOS and loader images.

- A 1 GB flash part holds configuration files, kickstart images, systems images, and other files.

The upgradeable BIOS and the golden BIOS are programmed onto the 2 MB flash part. You cannot upgrade the golden BIOS.

When you download a new pair of kickstart and system images, you also get a new BIOS image because it is included in the system image. You can use the install all command to upgrade the kickstart, system, and upgradeable BIOS images.

This section includes the following topics:

- Starting the Switch

- Boot Sequence

Starting the Switch

A Cisco Nexus 5000 Series switch starts its boot process as soon as its power cord is connected to an A/C source. The switch does not have a power switch.

Boot Sequence

When the switch boots, the golden BIOS validates the checksum of the upgradeable BIOS. If the checksum is valid, then control is transferred to the upgradeable BIOS image. The upgradeable BIOS launches the kickstart image, which then launches the system image. If the checksum of the upgradeable BIOS is not valid, then the golden BIOS launches the kickstart image, which then launches the system image.

You can force the switch to bypass the upgradeable BIOS and use the golden BIOS instead. If you press Ctrl-Shift-6 within two seconds of when power is supplied to the switch, the golden BIOS will be used to launch the kickstart image, even if the checksum of the upgradeable BIOS is valid.

Note When you press Ctrl-Shift-6, the console settings must be set to their defaults: 9600 baud, 8 data bits, no parity, and 1 stop bit.

Before the boot sequence starts, the BIOS performs internal tests on the switch. If the tests fail, then the loader does not gain control. Instead, the BIOS image retains control and prints a message to the console at 9600 baud every 30 seconds that indicates a failure.

Figure 1-1 shows the normal and recovery boot sequence.

Figure 1-1 Boot Sequence

For information about recovery procedures, see Chapter1, “Troubleshooting”

Console Settings

The loader, kickstart, and system images have the following factory default console settings:

- Speed—9600 baud

- Databits—8 bits per byte

- Stopbits—1 bit

- Parity—none

These settings are stored on the switch, and all three images use the stored console settings.

To change a console setting, use the line console command in configuration mode. The following example configures a line console and sets the options for that terminal line:

switch# configure terminal

switch(config)# line console

switch(config-console)# databits 7

switch(config-console)# exec-timeout 30

switch(config-console)# parity even

switch(config-console)# stopbits 2

You cannot change the BIOS console settings. These are the same as the default console settings.

Upgrading the Switch

Note Users with the network-admin role can upgrade the software image on the switch.

This section includes the following topics:

- Upgrade Procedure Summary

- Detailed Upgrade Procedure

Upgrade Procedure Summary

The following summary procedure describes how to upgrade the switch software:

Step 1 Log in to the console port on the supervisor module.

Step 2 Log in to Cisco.com and download the kickstart and system images to a server.

Step 3 Download the kickstart and system images to the switch using the copy command.

Step 4 Install the images using the install all command.

Caution While the switch performs the installation, all traffic through the switch is disrupted.

Detailed Upgrade Procedure

Caution Upgrading a Cisco Nexus 5000 Series switch disrupts all traffic flow through the switch.

To upgrade the software on the switch, follow these steps:

Step 1 Log in to the switch on the console port connection.

Step 2 Log in to Cisco.com to access the Software Download Center. To log in to Cisco.com, go to the URL http://www.cisco.com/ and click Log In at the top of the page. Enter your Cisco username and password.

Note Unregistered Cisco.com users cannot access the links provided in this document.

Step 3 Access the Software Download Center using this URL:

http://www.cisco.com/kobayashi/sw-center/index.shtml

Step 4 Navigate to the software downloads for Cisco Nexus 5000 Series switches.

You see links to the download images for the switch.

Step 5 Read the release notes for the related image file.

Step 6 Select and download the kickstart and system software files to a server.

Step 7 Ensure that the required space is available in the bootflash: directory for the image file(s) to be copied.

switch# dir bootflash:

5910 Jun 17 14:48:28 2008 config0617

453 Jan 01 00:12:13 2005 ent-fm.lic

453 Jan 01 20:50:55 2005 ent-fm123.lic

453 Jan 01 20:58:49 2005 ent-fm123456.lic

215 Jan 01 00:13:50 2005 enterprise.lic

221 Jan 01 04:25:43 2005 eth-mod.lic

219 Jan 01 04:26:14 2005 eth-port.lic

216 Jan 01 00:21:48 2005 fc-feature.lic

49152 Jul 28 09:42:51 2008 lost+found/

21581824 Jul 08 10:11:14 2008 n5000-uk9-kickstart.4.0.0.N1.1.445.bin

21573632 Jul 28 09:38:33 2008 n5000-uk9-kickstart.4.0.0.N1.1.47.bin

20062208 Jul 28 09:43:05 2008 n5000-uk9-kickstart.4.0.0.N1.2.467.bin

77139580 Jul 08 10:10:45 2008 n5000-uk9.4.0.0.N1.1.445.bin

75270834 Jul 28 09:38:33 2008 n5000-uk9.4.0.0.N1.1.47.bin

76924383 Jul 28 09:44:01 2008 n5000-uk9.4.0.0.N1.2.467.bin

4096 Jan 01 00:07:37 2005 routing-sw/

3697 Apr 30 14:53:07 2008 startup-config

4096 Aug 08 12:49:09 2008 test/

0 Jan 03 04:19:13 2005 thttpd_output

782893 Jan 21 16:56:14 2005 zone-scale-config.out

126927 Jan 21 16:55:45 2005 zoneset-scale-config.out

Usage for bootflash://sup-local

855547904 bytes used

6942613504 bytes free

7798161408 bytes total

Tip We recommend that you keep the kickstart and system image files for at least one previous software release to use if the new image files do not load successfully.

Step 8 If you need more space on the active supervisor module bootflash, delete unnecessary files to make space available.

switch# delete bootflash:n5000-uk9-kickstart.4.0.0.N1.1.445.bin

switch# delete bootflash:n5000-uk9.4.0.0.N1.1.445.bin

Step 9 Copy the kickstart and system images to the supervisor module bootflash using a transfer protocol. You can use ftp:, tftp:, scp:, or sftp:. The examples in this procedure use scp:.

switch# copy scp://user@scpserver.cisco.com//downloads/n5000-uk9-kickstart.4.0.0.N1.2.bin bootflash:n5000-uk9-kickstart.4.0.0.N1.2.bin

switch# copy scp://user@scpserver.cisco.com//downloads/n5000-uk9.4.0.0.N1.2.bin bootflash:n5000-uk9.4.0.0.N1.2.bin

Step 10 Install the new images, specifying the new image names that you downloaded in step 9.

switch(config)# install all kickstart bootflash:n5000-uk9-kickstart.4.0.0.N1.2.bin system bootflash:n5000-uk9.4.0.0.N1.2.bin

The install command performs the following actions:

- performs compatibility checks (equivalent to the show incompatibility command) for the images that you have specified. If there are compatibility issues, an error message is displayed and the installation does not proceed.

- Displays the compatibility check results and displays whether the installation is disruptive.

- Provides a prompt to allow you to continue or abort the installation.

Note A disruptive installation causes traffic disruption while the switch reboots.

- Updates the boot variables to reference the specified images and saves the configuration to the startup configuration file.

Step 11 After the switch completes the installation, log in and verify that the switch is running the required software version.

switch# show version

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Copyright (c) 2002-2008, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained herein are owned by

other third parties and are used and distributed under license.

Some parts of this software may be covered under the GNU Public

License or the GNU Lesser General Public License. A copy of

each such license is available at

http://www.gnu.org/licenses/gpl.html and

http://www.gnu.org/licenses/lgpl.html

Software

BIOS: version 1.2.0

kickstart: version 4.0(0)N1(2)

system: version 4.0(0)N1(2)

BIOS compile time: 06/19/08

kickstart image file is: bootflash:/n5000-uk9-kickstart.4.0.0.N1.2.467.bin

kickstart compile time: 7/28/2008 2:00:00 [07/28/2008 09:41:24]

system image file is: bootflash:/n5000-uk9.4.0.0.N1.2.467.bin

system compile time: 7/28/2008 2:00:00 [07/28/2008 10:09:17]

Hardware

cisco Nexus5020 Chassis ("40x10GE/Supervisor")

Intel(R) Celeron(R) M CPU with 2074164 kB of memory.

Processor Board ID JAB120600AY

bootflash: 7864320 kB

nms-eugene-02 kernel uptime is 11 days 3 hours 15 minute(s) 19 second(s)

Last reset at 63897 usecs after Mon Jul 28 09:46:39 2008

Reason: Reset by installer

System version: 4.0(0)N1(1)

Service:

Downgrading from a Higher Release

Note Only users with the network-admin role can downgrade the software image.

The procedure to downgrade the switch is identical to a switch upgrade, except that the image files to be loaded are for an earlier release than the image currently running on the switch.

Note Prior to downgrading to a specific release, check the release notes for the current release installed on the switch, to ensure that your hardware is compatible with the specific release.

To downgrade the software on the switch, follow these steps:

Step 1 Locate the image files you will use for the downgrade by entering the dir bootflash: command.

If the image files are not stored on the bootflash memory, download the files from Cisco.com (using steps 1 through 9 of the software upgrade procedure).

Step 2 Install the new images.

switch(config)# install all kickstart bootflash:n5000-uk9-kickstart.4.0.0.N1.1a.bin system bootflash:n5000-uk9.4.0.0.N1.1a.bin

The install all command performs the following actions:

- performs compatibility checks (equivalent to the show incompatibility command) for the images that you have specified. If there are compatibility issues, an error message is displayed and the installation does not proceed.

- Displays the compatibility check results and displays whether the installation is disruptive.

- Provides a prompt to allow you to continue or abort the installation.

Note A disruptive installation causes traffic disruption while the switch reboots.

- updates the boot variables to reference the specified images and saves the configuration to the startup configuration file.

Step 3 After the switch completes the installation, log in and verify that the switch is running the required software version.

switch# show version

Initial Configuration

The section includes the following topics:

- Configuration Prerequisites

- Initial Setup

- Preparing to Configure the Switch

- Default Login

- Configuring the Switch

- Changing the Initial Configuration

Configuration Prerequisites

The following procedure is a review of the tasks you should have completed during hardware installation. These tasks must be completed before you can configure the switch.

Before you can configure a switch, follow these steps:

Step 1 Verify the following physical connections for the new Cisco Nexus 5000 Series switch:

- The console port is physically connected to a computer terminal (or terminal server).

- The management Ethernet port (mgmt0) is connected to an external hub, switch, or router.

Refer to the Cisco Nexus 5000 Series Hardware Installation Guide (for the required product) for more information.

Tip Save the host ID information for future use (for example, to enable licensed features). The host ID information is provided in the Proof of Purchase document that accompanies the switch.

Step 2 Verify that the default console port parameters are identical to those of the computer terminal (or terminal server) attached to the switch console port:

- 9600 baud

- 8 data bits

- No parity

- 1 stop bit

Initial Setup

The first time that you access a switch in the Cisco Nexus 5000 Series, it runs a setup program that prompts you for the IP address and other configuration information necessary for the switch to communicate over the Ethernet interface. This information is required to configure and manage the switch.

Note The IP address can only be configured from the CLI. When the switch powers up for the first time, you should assign the IP address. After you perform this step, the Cisco MDS 9000 Family Fabric Manager can reach the switch through the console port.

Preparing to Configure the Switch

Before you configure Cisco Nexus 5000 Series switch for the first time, you need the following information:

- Administrator password.

Note If a password is weak (short, easy-to-decipher), your password configuration is rejected. Be sure to configure a strong password.

- If you are using an IPv4 address for the management interface, you need the following information:

– IPv4 subnet mask for the switch’s management interface.

– IPv4 address of the default gateway (optional).

- SSH service on the switch (optional).

To enable this service, select the type of SSH key (dsa/rsa/rsa1) and number of SSH key bits (768 to 2048).

- NTP server IPv4 address (optional).

- SNMP community string (optional).

- Switch name (optional).

This is your switch prompt.

- An additional login account and password (optional).

Note If you are using IPv4, be sure to configure the IPv4 route, the IPv4 default network address, and the IPv4 default gateway address to enable SNMP access.

Default Login

The switch has the network administrator as a default user (admin). You cannot change the default user at any time.

There is no default password so you must explicitly configure a strong password. If a password is trivial (short, easy-to-decipher), your password configuration is rejected. Be sure to configure a strong password. If you configure and subsequently forget this new password, you have the option to recover this password.

Note If you enter a write erase command and reload the switch, you must reconfigure the default user (admin) password using the setup procedure.

Configuring the Switch

This section describes how to initially configure the switch.

Note Press Ctrl-C at any prompt to skip the remaining configuration options and proceed with what you have configured up to that point. Entering the new password for the administrator is a requirement and cannot be skipped.

Tip If you do not want to answer a previously configured question, or if you want to skip answers to any questions, press Enter. If a default answer is not available (for example, switch name), the switch uses what was previously configured and skips to the next question.

To configure the switch for first time, follow these steps:

Step 1 Ensure that the switch is on. Switches in the Cisco Nexus 5000 Series boot automatically.

Step 2 Enter the new password for the administrator.

Enter the password for admin: password

Tip If a password is weak (short, easy-to-decipher), your password configuration is rejected. Be sure to configure a strong password. Passwords are case-sensitive.

Step 3 Enter yes to enter the setup mode.

This setup utility will guide you through the basic configuration of

the system. Setup configures only enough connectivity for management

of the system.

*Note: setup is mainly used for configuring the system initially,

when no configuration is present. So setup always assumes system

defaults and not the current system configuration values.

Press Enter at anytime to skip a dialog. Use ctrl-c at anytime

to skip the remaining dialogs.

Would you like to enter the basic configuration dialog (yes/no): yes

The setup utility guides you through the basic configuration process. Press Ctrl-C at any prompt to end the configuration process.

Step 4 Enter the new password for the administrator (admin is the default).

Enter the password for admin: admin

Step 5 Enter yes (no is the default) to create additional accounts.

Create another login account (yes/no) [n]: yes

While configuring your initial setup, you can create an additional user account (in the network-admin role) besides the administrator’s account. See the “Configuring RBAC” section for information on default roles and permissions.

a. Enter the user login ID.

Enter the user login ID: user_name

b. Enter the user password.

Enter the password for user_name: user-password

Step 6 Enter yes (yes is the default) to create an SNMP read-only community string.

Configure read-only SNMP community string (yes/no) [n]: yes

SNMP community string: snmp_community

Step 7 Enter a name for the switch.

Note The switch name is limited to 32 alphanumeric characters. The default is switch.

Enter the switch name: switch_name

Step 8 Enter yes (yes is the default) to configure out-of-band management.

Continue with Out-of-band (mgmt0) management configuration? [yes/no]: yes

a. Enter the mgmt0 IPv4 address.

Mgmt0 IPv4 address: ip_address

Step 9 Enter yes (yes is the default) to configure the IPv4 default gateway (recommended).

Configure the default-gateway: (yes/no) [y]: yes

a. Enter the default gateway IPv4 address.

IPv4 address of the default-gateway: default_gateway

Step 10 Enter yes (yes is the default) to enable the Telnet service.

Enable the telnet service? (yes/no) [y]: yes

Step 11 Enter yes (no is the default) to enable the SSH service.

Enabled SSH service? (yes/no) [n]: yes

Step 12 Enter the SSH key type that you would like to generate.

Type the SSH key you would like to generate (dsa/rsa/rsa1)? dsa

Step 13 Enter the number of key bits within the specified range.

Enter the number of key bits? (768 to 2048): 768

Step 14 Enter yes (no is the default) to configure the NTP server.

Configure NTP server? (yes/no) [n]: yes

a. Enter the NTP server IPv4 address.

NTP server IP address: ntp_server_IP_address

Step 15 Enter yes (yes is the default) to configure basic Fibre Channel configurations.

Enter basic FC configurations (yes/no) [n]: yes

Step 16 Enter shut (shut is the default) to configure the default Fibre Channel switch port interface to the shut (disabled) state.

Configure default physical FC switchport interface state (shut/noshut) [shut]: shut

Step 17 Enter on (on is the default) to configure the switch port trunk mode.

Configure default physical FC switchport trunk mode (on/off/auto) [on]: on

Step 18 Enter permit (deny is the default) to deny a default zone policy configuration.

Configure default zone policy (permit/deny) [deny]: permit

Permits traffic flow to all members of the default zone.

Note If you are executing the setup script after entering a write erase command, you explicitly must change the default zone policy to permit for VSAN 1 after finishing the script using the following command:

switch(config)# zone default-zone permit vsan 1

Step 19 Enter yes (no is the default) to enable a full zone set distribution.

Enable full zoneset distribution (yes/no) [n]: yes

Overrides the switch-wide default for the full zone set distribution feature.

You see the new configuration. Review and edit the configuration that you have just entered.

Step 20 Enter no (no is the default) if you are satisfied with the configuration.

The following configuration will be applied:

username admin password <user-password> role network-admin

snmp-server community snmp_community ro

switchname switch

telnet server enable

ssh key dsa 768 force

ssh server enable

system default switchport shutdown san

system default switchport trunk mode on

system default zone default-zone permit

system default zone distribute full

Would you like to edit the configuration? (yes/no) [n]: no

Step 21 Enter yes (yes is default) to use and save this configuration:

Use this configuration and save it? (yes/no) [y]: yes

Caution If you do not save the configuration at this point, none of your changes are updated the next time the switch is rebooted. Type yes to save the new configuration. This operation ensures that the kickstart and system images are also automatically configured (see “Image Files on the Switch” section).

Changing the Initial Configuration

To make changes to the initial configuration at a later time, enter the setup command in EXEC mode:

switch# setup

---- Basic System Configuration Dialog ----

This setup utility will guide you through the basic configuration of

the system. Setup configures only enough connectivity for management

of the system.

*Note: setup is mainly used for configuring the system initially,

when no configuration is present. So setup always assumes system

defaults and not the current system configuration values.

Press Enter at anytime to skip a dialog. Use ctrl-c at anytime

to skip the remaining dialogs.

Would you like to enter the basic configuration dialog (yes/no): yes

The setup utility guides you through the basic configuration process.

Accessing the Switch

After the initial configuration, you can access the switch in a number of ways:

- Serial console access—You can use a serial port connection to access the CLI.

- Out-of-band access—You can use Telnet or SSH to access a Cisco Nexus 5000 Series switch or use the Cisco MDS 9000 Fabric Manager application to connect to the switch using SNMP.

Additional Switch Configuration

This section includes the following topics:

- Assigning a Switch Name

- Configuring Date, Time, and Time Zone

- Adjusting for Daylight Saving Time or Summer Time

Assigning a Switch Name

Each switch in the network requires a unique name. You can assign names to easily identify the switch by its physical location, its network association, or the organization to which it is deployed. The assigned name is displayed in the command-line prompt. The switch name is limited to 20 alphanumeric characters.

Note This guide refers to a switch in the Cisco Nexus 5000 Series switch as switch, and it uses the switch# prompt.

To change the name of the switch, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# switchname myswitch1

myswitch1(config)#

Changes the switch name prompt as specified (myswitch1).

Step 3

myswitch1(config)# no switchname

switch(config)#

Reverts the switch name prompt to its default (switch#).

Configuring Date, Time, and Time Zone

The Cisco Nexus 5000 Series switches use Universal Coordinated Time (UTC), which is the same as Greenwich Mean Time (GMT). To change the default time on the switch, perform this task:

Command

Purpose

switch# clock set HH:MM:SS DD Month YYYY

Sets the default time on the switch. HH represents hours in 24-hour time (15 for 3 P.M.), MM is minutes (58), SS is seconds (09), DD is the date (29), Month is the month in words (February), and YYYY is the year (2008).

The following example sets the time for the switch:

switch# clock set 15:58:09 29 February 2008

Mon Feb 20 15:58:09 UTC 2008

Note The clock command changes are saved across system resets.

You can specify a time zone for the switch. To specify the local time without the daylight saving time feature, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# clock timezone timezone hours_offset minutes_offset

Sets the time zone. timezone is the three letter time zone (PST for Pacific Standard), the hours offset from UTC (-8 for the PST offset), and minutes offset (needed for time zones such as Newfoundland Standard (NST) or India Standard (IST)).

Step 3

switch(config)# exit

Returns to EXEC mode.

Step 4

switch# show clock

Verifies the time zone configuration.

Step 5

switch# show run

Displays changes made to the time zone configuration along with other configuration information.

The following example sets the time zone to Pacific Standard Time (PST) and offsets the UTC time by negative eight hours and 0 minutes:

switch# configure terminal

switch(config)# clock timezone PST -8 0

To disable the local time setting, perform this task:

switch(config)# no clock timezone

Disables the time zone adjustment feature.

Adjusting for Daylight Saving Time or Summer Time

You can configure your switch to adjust for daylight saving time (or summer time). By default, Cisco NX-OS does not automatically adjust for daylight saving time. You must manually configure the switch to adjust to the daylight saving time.

For example, following U.S. standards (defined by the Energy Policy Act of 2005), you can have the switch advance the clock one hour at 2:00 a.m. on the second Sunday in March and move back the clock one hour at 2:00 a.m. on the first Sunday in November. You can also explicitly specify the start and end dates and times and whether or not the time adjustment recurs every year.

To enable the daylight saving time clock adjustment, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# clock summer-time timezone start_week start_day start_month start_time end_week end_day end_month end_time offset

Sets the daylight savings time for a specified time zone.

The start and end values are as follows:

- Week ranging from 1 through 5

- Day ranging from Sunday through Saturday

- Month ranging from January through December

The daylight offset ranges from 1 through 1440 minutes, which are added to the start time and deleted time from the end time.

switch(config)# no clock summer-time

Disables the daylight saving time adjustment feature.

Step 3

switch(config)# exit

switch#

Returns to EXEC mode.

Step 4

switch# show running-config | include summer-time

Verifies the time zone configuration.

The following example adjusts the daylight savings time for the U.S. Pacific daylight time by 60 minutes starting the second Sunday in March at 2 a.m. and ending the first Sunday in November at 2 a.m:

switch# configure terminal

switch(config)# clock summer-time PDT 1 Sunday March 02:00 1 Sunday November 02:00 60

NTP Configuration

A Network Time Protocol (NTP) server provides a precise time source (radio clock or atomic clock) to synchronize the system clocks of network devices. NTP is transported over User Datagram Protocol UDP/IP. All NTP communications use Universal Time Coordinated (UTC). An NTP server receives its time from a reference time source, such as a radio clock or atomic clock, attached to the time. NTP distributes this time across the network.

This section includes the following sections:

- About NTP

- NTP Configuration Guidelines

- Configuring NTP

- NTP CFS Distribution

About NTP

In a large enterprise network, having one time standard for all network devices is critical for management reporting and event logging functions when trying to correlate interacting events logged across multiple devices. Many enterprise customers with extremely mission-critical networks maintain their own stratum-1 NTP source.

Time synchronization happens when several frames are exchanged between clients and servers. The switches in client mode know the address of one or more NTP servers. The servers act as the time source and receive client synchronization requests.

By configuring an IP address as a peer, the switch will obtain and provide time as required. The peer is capable of providing time on its own and is capable of having a server configured. If both these instances point to different time servers, your NTP service is more reliable. Even if the active server link is lost, you can still maintain the right time due to the presence of the peer.

Tip If an active server fails, a configured peer helps in providing the NTP time. Provide a direct NTP server association and configure a peer to ensure backup support if the active server fails.

If you only configure a peer, the most accurate peer takes on the role of the NTP server and the other peer(s) acts as a peer(s).

NTP Configuration Guidelines

The following guidelines apply to all NTP configurations:

- You should have a peer association with another switch only when you are sure that your clock is reliable (which means that you are a client of a reliable NTP server).

- A peer configured alone takes on the role of a server and should be used as backup. If you have two servers, then you can have several switches point to one server, and the remaining switches to the other server. You would configure peer association between these two sets, which forces the clock to be more reliable.

- If you only have one server, it is better for all the switches to have a client association with that server.

Not even a server down time will affect well-configured switches in the network. Figure 1-2 displays a network with two NTP stratum 2 servers and two switches.

Figure 1-2 NTP Peer and Server Association

In this configuration, the switches were configured as follows:

- Stratum 2 Server 1

– IPv4 address–10.10.10.10

– Stratum–2 Server-2

– IPv4 address–10.10.10.9

- Switch 1 IPv4 address–10.10.10.1

- Switch 1 NTP configuration commands

– ntp server 10.10.10.10

– ntp peer 10.10.10.2

- Switch 2 IPv4 address–10.10.10.2

- Switch 2 NTP configuration commands

– ntp server 10.10.10.9

– ntp peer 10.10.10.1

Configuring NTP

You can configure NTP using either IPv4 addresses, IPv6 addresses, or Domain Name Services (DNS) names. To configure NTP associations, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# ntp server {ip-address | ipv6-address | dns-name}

Forms an association with a server.

Step 3

switch(config)# ntp peer {ip-address | ipv6-address | dns-name}

Forms an association with a peer. You can specify multiple associations.

Step 4

switch(config)# exit

Returns to EXEC mode.

Step 5

switch# copy running-config startup-config

Saves your configuration changes to NVRAM.

Tip This is one instance where you can save the configuration as a result of an NTP configuration change. You can enter this command at any time.

Step 6

switch# show ntp peers

Displays the configured server and peer associations.

NTP CFS Distribution

You can enable NTP fabric distribution for all Cisco Nexus 5000 Series switches in a fabric using the Cisco Fabric Services (CFS). When you perform NTP configurations, and distribution is enabled, the entire server or peer configuration is distributed to all the switches in the fabric.

You automatically acquire a fabric-wide lock when you enter the first configuration command after you enabled distribution in a switch.The NTP application uses an effective and pending database model to store or commit the commands based on your configuration. You changes are stored in the pending database and committed to the effective database.

See the “Information About CFS” section for more information on the CFS application.

This section includes the following sections:

- Enabling NTP Distribution

- Committing NTP Configuration Changes

- NTP Session Status Verification

- Database Merge Guidelines

- NTP Session Status Verification

Enabling NTP Distribution

To enable NTP configuration fabric distribution, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# ntp distribute

Enables NTP configuration distribution to all switches in the fabric. Acquires a fabric lock and stores all future configuration changes in the pending database.

switch(config)# no ntp distribute

Disables (default) NTP configuration distribution to all switches in the fabric.

Committing NTP Configuration Changes

When you commit the NTP configuration changes, the effective database is overwritten by the configuration changes in the pending database and all the switches in the fabric receive the same configuration. When you commit the NTP configuration changes without implementing the session feature, the NTP configurations are distributed to all the switches in the fabric.

To commit the NTP configuration changes, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# ntp commit

Distributes the NTP configuration changes to all switches in the fabric and releases the lock. Overwrites the effective database with the changes made to the pending database.

Discarding NTP Configuration Changes

After making the configuration changes, you can choose to discard the changes or to commit them. In either case, the lock is released.

To discard NTP configuration changes, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# ntp abort

Discards the NTP configuration changes in the pending database and releases the fabric lock.

Releasing Fabric Session Lock

If you have performed an NTP fabric task and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.

Tip The changes are only available in the volatile directory and are subject to being discarded if the switch is restarted.

To use administrative privileges and release a locked NTP session, use the clear ntp session command.

switch# clear ntp session

Database Merge Guidelines

When merging two fabrics, follow these guidelines:

- Be aware that the merge is a union of the existing and the received database in each switch in the fabric.

- Do not configure an IP address as a server on one switch and as a peer on another switch. The merge can fail if this configuration exists.

- Verify that the union of the databases does not exceed the maximum limit of 64.

NTP Session Status Verification

To verify the status of the NTP session, use the show ntp session-status command.

switch# show ntp session-status

last-action : Distribution Enable Result : Success

Management Interface Configuration

The management interface on the switch allows multiple simultaneous Telnet or SNMP sessions. You can remotely configure the switch through the management interface (mgmt0), but first you must configure some IP parameters so that the switch is reachable. You can manually configure the management interface from the CLI.

This section includes the following sections:

- About the mgmt0 Interface

- Configuring the Management Interface

- Displaying Management Interface Configuration

- Shutting Down the Management Interface

About the mgmt0 Interface

The mgmt0 interface on Cisco NX-OS devices provides out-of-band management, which enables you to manage the device by its IPv4 or IPv6 address. The mgmt0 interface uses 10/100/1000 Ethernet.

Note Before you begin to configure the management interface manually, obtain the switch’s IP address and subnet mask. Also make sure that the console cable is connected to the console port.

Configuring the Management Interface

To configure the management (mgmt0) Ethernet interface to connect over IP, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# interface mgmt 0

Selects the management Ethernet interface on the switch and enters interface configuration submode.

Step 3

switch(config-if)# ip address ipv4-address[/length]

Configures the IPv4 address and its subnet mask.

switch(config-if)# ip address ipv4-address [subnet-mask]

An alternative method that configures the IPv4 address and its subnet mask.

switch(config-if)# ipv6 address ipv6-address[/length]

Configures the IPv6 address and its subnet mask.

Step 4

switch(config-if)# no shutdown

Enables the interface.

Step 5

switch(config-if)# exit

Returns to configuration mode.

Step 6

switch(config)# vrf context management

Enters VRF context management configuration mode.

Step 7

switch(config-vrf)# ip route ipv4-prefix[/length] ipv4-nexthop-address

Configures the IPv4 address of the next hop.

switch(config-vrf)# ipv6 route ipv6-prefix[/length] ipv6-nexthop-address

Configures the IPv6 address of the next hop.

Step 8

switch(config-vrf)# exit

Returns to EXEC mode.

Step 9

switch# copy running-config startup-config

(Optional) Saves your configuration changes to the file system.

In some cases, a switch interface might be administratively shut down. You can check the status of an interface at any time by using the show interface mgmt 0 command.

Displaying Management Interface Configuration

To display the management interface configuration, use the show interface mgmt 0 command.

switch# show interface mgmt0

mgmt0 is up

Hardware is GigabitEthernet, address is 000d.ec8f.cb00 (bia 000d.ec8f.cb00)

Internet Address is 172.16.131.202/24

MTU 1500 bytes, BW 0 Kbit, DLY 0 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA

full-duplex, 1000 Mb/s

Input flow-control is off, output flow-control is off

8540 packets input, 2835036 bytes

5202 multicast frames, 0 compressed

0 input errors, 0 frame, 0 overrun, 0 fifo

570 packets output, 85555 bytes

0 underrun, 0 output errors, 0 collisions

0 fifo, 0 carrier errors

switch#

Shutting Down the Management Interface

To shut down the management interface (mgmt0), you use the shutdown command. A system prompt requests you confirm your action before it executes the command. You can use the force option to bypass this confirmation. The following example shuts down the interface without using the force option:

switch# configure terminal

switch(config)# interface mgmt 0

switch(config-if)# shutdown

Shutting down this interface will drop all telnet sessions.

Do you wish to continue (y/n)? y

The following example shuts down the interface using the force option:

switch# configure terminal

switch(config)# interface mgmt 0

switch(config-if)# shutdown force

Managing the Switch Configuration

This section includes the following topics:

- Displaying the Switch Configuration

- Saving a Configuration

- Clearing a Configuration

Displaying the Switch Configuration

You can view the ASCII form of the configuration file when required. To view the current configuration tree from the EXEC prompt, enter the show running-config command. If the running configuration is different from the startup configuration, enter the show startup-config command to view the ASCII version of the current startup configuration that was used to boot the switch if a copy running-config startup-config command was not entered after the reboot. Use the show startup-config command to view the contents of the current startup configuration.

You can also gather specific information on the entire switch configuration by entering the relevant show commands. Configurations are displayed based on a specified feature, interface, module, or VSAN. Available show commands for each feature are briefly described in this section and listed at the end of each chapter.

Saving a Configuration

Use the copy running-config startup-config command to save the new configuration into nonvolatile storage. Once this command is entered, the running and the startup copies of the configuration are identical.

Clearing a Configuration

Use the write erase command to clear a startup configuration. Once this command is executed, the switch’s startup configuration reverts to factory defaults. The running configuration is not affected.

Caution The write erase command erases the entire startup configuration with the exception of any configuration that affects the loader functionality.

The write erase boot command only erases the configuration that affects the loader functionality. The loader functionality configuration includes the boot variables and the mgmt0 IP configuration information (IP address, netmask, and default gateway).

switch# write erase boot

This command will erase the boot variables and the IP configuration of interface mgmt 0.

Using Switch File Systems

This section includes the following topics:

- Setting the Current Directory

- Displaying the Current Directory

- Listing the Files in a Directory

- Creating a Directory

- Deleting an Existing Directory

- Moving Files

- Copying Files

- Deleting Files

- Displaying File Contents

- Saving Command Output to a File

- Compressing and Uncompressing Files

Setting the Current Directory

The cd command changes the current directory level to a specified directory level. The CLI defaults to the volatile: file system. This command expects a directory name input.

Any file saved in the volatile: file system is erased when the switch reboots.

The syntax for this command is cd directory name.

This command exchanges the current directory to the root directory on the bootflash: file system:

switch# cd bootflash:

This example changes the current directory to the mystorage directory that resides in the current directory:

switch# cd mystorage

Displaying the Current Directory

The pwd command displays the current directory location. This example changes the directory and displays the current directory:

switch# cd bootflash:

switch# pwd

bootflash:

Listing the Files in a Directory

The dir command displays the contents of the current directory or the specified directory. The syntax for this command is dir directory or dir filename.

This example shows how to list the files on the default volatile: file system:

switch# dir

Usage for volatile: filesystem

0 bytes total used

20971520 bytes free

20971520 bytes available

Creating a Directory

The mkdir command creates a directory at the current directory level or at a specified directory level.

The syntax for this command is mkdir directory name.

This example creates a directory called test in the bootflash: directory.

switch# mkdir bootflash:test

This example creates a directory called test at the current directory level.

switch# mkdir test

Deleting an Existing Directory

The rmdir command deletes an existing directory at the current directory level or at a specified directory level. The directory must be empty to be deleted.

The syntax for this command is rmdir directory name.

This example deletes the directory called test in the bootflash directory:

switch# rmdir bootflash:test

This is a directory. Do you want to continue (y/n)? [y] y

The delete command can also delete empty and non empty directories. When you enter this command, a warning is displayed to confirm your intention to delete the directory.

This example deletes the directory called test at the current directory level:

switch# delete test

This is a directory. Do you want to continue (y/n)? [y] y

If the current directory is bootflash:mydir, this command deletes the bootflash:mydir/test directory.

Moving Files

The move command removes a file from the source directory and places it in the destination directory

Caution If a file with the same name already exists in the destination directory, that file is overwritten by the moved file.

This example moves the file called samplefile from the root directory to the mystorage directory:

switch# move bootflash:samplefile bootflash:mystorage/samplefile

This example moves a file from the current directory level:

switch# move samplefile mystorage/samplefile

If the current directory is bootflash:mydir, this command moves bootflash:mydir/samplefile to bootflash:mydir/mystorage/samplefile.

Copying Files

The copy command copies a file between file systems within a switch.

Note Use the dir command to ensure that enough space is available in the target file system. If enough space is not available, use the delete command to remove unneeded files.

This example copies the file called samplefile from the root directory to the mystorage directory:

switch# copy bootflash:samplefile bootflash:mystorage/samplefile

This example copies a file from the current directory level:

switch# copy samplefile mystorage/samplefile

If the current directory is bootflash:mydir, this command copies bootflash:mydir/samplefile to bootflash:mydir/mystorage/samplefile.

Deleting Files

The delete command deletes a specified file or the specified directory and all its contents.

This example shows how to delete a file from the current working directory:

switch# delete dns_config.cfg

This example deletes the entire bootflash: directory and all its contents:

switch# delete bootflash:my-dir

Caution If you specify a directory, the delete command deletes the entire directory and all its contents.

Displaying File Contents

The show file command displays the contents of a specified file in the file system.

This example displays the contents of a file residing in the current directory:

switch# show file myfile

Saving Command Output to a File

You can force all screen output to go to a file by appending > filename to any command. For example, enter show interface > samplefile at the EXEC mode switch prompt to save the interface configuration to samplefile which is a file created at the same directory level. At the EXEC mode switch prompt, enter a dir command to view all files in this directory, including the recently saved samplefile.

Compressing and Uncompressing Files

The gzip command compresses (zips) the specified file using LZ77 coding.

This example directs the output of the show tech-support command to a file (Samplefile), and then zips the file and displays the difference in the space used up in the volatile: directory:

switch# show tech-support > Samplefile

Building Configuration ...

switch# dir

1525859 Jul 04 00:51:03 2003 Samplefile

Usage for volatile://

1527808 bytes used

19443712 bytes free

20971520 bytes total

switch# gzip volatile:Samplefile

switch# dir

266069 Jul 04 00:51:03 2003 Samplefile.gz

Usage for volatile://

266240 bytes used

20705280 bytes free

20971520 bytes total

The gunzip command uncompresses (unzips) LZ77 coded files.

This example unzips the file that was compressed in the previous example:

switch# gunzip samplefile

switch# dir

1525859 Jul 04 00:51:03 2003 Samplefile

Usage for volatile://

1527808 bytes used

19443712 bytes free

20971520 bytes total

Configuring N Port Virtualization

This chapter describes how to configure N port virtualization (NPV) on Cisco Nexus 5000 Series switches.

This chapter includes the following sections:

- Information About NPV

- Guidelines and Limitations

- Configuring NPV

- Verifying NPV

Information About NPV

NPV configuration is described in the following topics:

- NPV Overview

- NPV Mode

- Server Interfaces

- NP Uplinks (External Interfaces)

- FLOGI Operation

- NPV Traffic Management

- NPV Traffic Management Guidelines

NPV Overview

By default, Cisco Nexus 5000 Series switches operate in fabric mode. In this mode, the switch provides standard Fibre Channel switching capability and features.

In fabric mode, each switch that joins a SAN is assigned a domain ID. Each SAN (or VSAN) supports a maximum of 239 domain IDs, so the SAN has a limit of 239 switches. In a SAN topology with a large number of edge switches, the SAN may need to grow beyond this limit. NPV alleviates the domain ID limit by sharing the domain ID of the core switch among multiple edge switches.

In NPV mode, the edge switch relays all traffic from server-side ports to the core switch. The core switch provides F port functionality (such as login and port security) and all the Fibre Channel switching capabilities.

The edge switch appears as a Fibre Channel host to the core switch and as a regular Fibre Channel switch to its connected devices.

Figure 1-1 shows an interface-level view of an NPV configuration.

Figure 1-1 NPV Interface Configuration

NPV Mode

In NPV mode, the edge switch relays all traffic to the core switch, which provides the Fibre Channel switching capabilities. The edge switch shares the domain ID of the core switch.

To convert a switch into NPV mode, you set the NPV feature to enabled. This configuration command automatically triggers a switch reboot. You cannot configure NPV mode on a per-interface basis. NPV mode applies to the entire switch.

In NPV mode, a subset of fabric mode CLI commands and functionality is supported. For example, commands related to fabric login and name server registration are not required on the edge switch, because these functions are provided in the core switch. To display the fabric login and name server registration databases, you must enter the show flogi database and show fcns database commands on the core switch.

Server Interfaces

Server interfaces are F ports on the edge switch that connect to the servers. A server interface may support multiple end devices by enabling the N port identifier virtualization (NPIV) feature. NPIV provides a means to assign multiple FC IDs to a single N port, which allows the server to assign unique FC IDs to different applications.

Note To use NPIV, enable the NPIV feature and reinitialize the server interfaces that will support multiple devices. For additional information about NPIV, see the “About N Port Identifier Virtualization” section.

Server interfaces are automatically distributed among the NP uplinks to the core switch. All of the end devices connected to a server interface are mapped to the same NP uplink.

In Cisco Nexus 5000 Series switches, server interfaces can be physical or virtual Fibre Channel interfaces.

NP Uplinks (External Interfaces)

All interfaces from the edge switch to the core switch are configured as proxy N ports (NP ports).

An NP uplink is a connection from an NP port on the edge switch to an F port on the core switch. When an NP uplink is established, the edge switch sends a fabric login message (FLOGI) to the core switch, and then (if the FLOGI is successful) it registers itself with the name server on the core switch. Subsequent FLOGIs from end devices connected to this NP uplink are converted to fabric discovery messages (FDISCs). For additional information about fabric login, see the “Information About Fabric Login” section.

Note In the switch CLI configuration commands and output displays, NP uplinks are called External Interfaces.

In Cisco Nexus 5000 Series switches, NP uplink interfaces must be native Fibre Channel interfaces.

FLOGI Operation

When an NP port becomes operational, the switch first logs itself in to the core switch by sending a FLOGI request (using the port WWN of the NP port).

After completing the FLOGI request, the switch registers itself with the fabric name server on the core switch (using the symbolic port name of the NP port and the IP address of the edge switch).

Table 1-1 identifies port and node names in the edge switch used in NPV mode.

Table 1-1 Edge Switch FLOGI Parameters

Parameter

Derived From

pWWN

The fWWN of the NP port on the edge switch.

nWWN

The VSAN-based sWWN of the edge switch.

symbolic port name

The edge switch name and NP port interface string.

Note If no switch name is available, the output will read “switch.” For example, switch: fc 1/5.

IP address

The IP address of the edge switch.

symbolic node name

The edge switch name.

Note The buffer-to-buffer state change number (BB_SCN) of internal FLOGIs on an NP port is always set to zero. The BB_SCN is supported by the F port on the edge switch.

We do not recommend using fWWN-based zoning on the edge switch for the following reasons:

- Zoning is not enforced at the edge switch (rather, it is enforced on the core switch).

- Multiple devices attached to an edge switch log in through the same F port on the core, so they cannot be separated into different zones.

- The same device might log in using different fWWNs on the core switch (depending on the NPV link it uses) and may need to be zoned using different fWWNs.

For additional information about zoning, see the “Information About Zoning” section.

NPV Traffic Management

Cisco Nexus 5000 Series switches provide NPV traffic management features. This section describes NPV traffic management and includes the following topics:

- Automatic Uplink Selection

- Traffic Maps

- Disruptive Load Balancing

Automatic Uplink Selection

NPV supports automatic selection of NP uplinks. When a server interface is brought up, the NP uplink interface with the minimum load is selected from the available NP uplinks in the same VSAN as the server interface.

When a new NP uplink interface becomes operational, the existing load is not redistributed automatically to include the newly available uplink. Server interfaces that become operational after the NP uplink can select the new NP uplink.

Traffic Maps

In Release 4.0(1a)N2(1) and later software releases, NPV supports traffic maps. A traffic map allows you to specify the NP uplinks that a server interface can use to connect to the core switches.

Note When an NPV traffic map is configured for a server interface, the server interface must select only from the NP uplinks in its traffic map. If none of the specified NP uplinks are operational, the server remains in a non-operational state.

The NPV traffic map feature provides the following benefits:

- Facilitates traffic engineering by allowing configuration of a fixed set of NP uplinks for a specific server interface (or range of server interfaces).

- Ensures correct operation of the persistent FC ID feature, because a server interface will always connect to the same NP uplink (or one of a specified set of NP uplinks) after an interface reinitialization or switch reboot.

Disruptive Load Balancing

In Release 4.0(0)N1(2a) and later software releases, NPV supports disruptive load balancing. When disruptive load balancing is enabled, NPV redistributes the server interfaces across all available NP uplinks when a new NP uplink becomes operational. To move a server interface from one NP uplink to another NP uplink, NPV forces reinitialization of the server interface so that the server performs a new login to the core switch.

Only server interfaces that are moved to a different uplink are reinitialized. A system message is generated for each server interface that is moved.

Note Redistributing a server interface causes traffic disruption to the attached end devices.

To avoid disruption of server traffic, you should enable this feature only after adding a new NP uplink, and then disable it again after the server interfaces have been redistributed.

If disruptive load balancing is not enabled, you can manually reinitialize some or all of the server interfaces to distribute server traffic to new NP uplink interfaces.

NPV Traffic Management Guidelines

When deploying NPV traffic management, follow these guidelines:

- Use NPV traffic management only when automatic traffic engineering does not meet your network requirements.

- You do not need to configure traffic maps for all server interfaces. By default, NPV will use automatic traffic management.

- Server interfaces configured to use a set of NP uplink interfaces cannot use any other available NP uplink interfaces, even if none of the configured interfaces are available.

- When disruptive load balancing is enabled, a server interface may be moved from one NP uplink to another NP uplink. Moving between NP uplink interfaces requires NPV to relogin to the core switch, causing traffic disruption.

- To link a set of servers to a specific core switch, associate the server interfaces with a set of NP uplink interfaces that all connect to that core switch.

- Configure Persistent FC IDs on the core switch and use the Traffic Map feature to direct server interface traffic onto NP uplinks that all connect to the associated core switch.

Guidelines and Limitations

When configuring NPV, note the following guidelines and limitations:

- In-order data delivery is not required in NPV mode because the exchange between two end devices always takes the same uplink from the edge switch to the core. Upstream of the edge switch, core switches will enforce in-order delivery if configured.

- You can configure zoning for end devices that are connected to edge switches using all available member types on the core switch. For fWWN, sWWN, domain, or port-based zoning, use the fWWN, sWWN, domain, or port of the core switch in the configuration commands.

- Port tracking is not supported in NPV mode.

- Port security is supported on the core switch for devices logged in through the NPV switch. Port security is enabled on the core switch on a per-interface basis. To enable port security on the core switch for devices that log in through an NPV switch, you must adhere to the following requirements:

– The internal FLOGI must be in the port security database; in this way, the port on the core switch will allow communications and links.

– All the end device pWWNs must also be in the port security database.

- Edge switches can connect to multiple core switches. In other words, different NP ports can be connected to different core switches.

- NPV uses a load-balancing algorithm to automatically assign end devices in a VSAN to one of the NP uplinks (in the same VSAN) upon initial login. If there are multiple NP uplinks in the same VSAN, you cannot assign an end device to a specific NP uplink.

- If a server interface goes down and then returns to service, the interface is not guaranteed to be assigned to the same NP uplink.

- The server interface is only operational when its assigned NP uplink is operational.

- Both servers and targets can be connected to the switch when in NPV mode.

- Fibre Channel switching is not performed in the edge switch; all traffic is switched in the core switch.

- NPV supports NPIV-capable servers. This capability is called nested NPIV.

- Connecting two Cisco NPV switches together is not supported.

- Only F, NP, and SD ports are supported in NPV mode.

Configuring NPV

Configuring NPV mode is described in the following topics:

- Enabling NPV

- Configuring NPV Interfaces

- Configuring NPV Traffic Management

Enabling NPV

When you enable NPV, the system configuration is erased and the switch reboots.

Note We recommend that you save your current configuration either in boot flash memory or to a TFTP server before you enable NPV.

Command

Purpose

Step 1

switch# configure terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# npv enable

Enables NPV mode. The switch reboots, and it comes back up in NPV mode.

Note A write-erase is performed during the initialization.

Step 3

switch(config-npv)# no npv enable

switch(config)#

Disables NPV mode, which results in a reload of the switch.

Configuring NPV Interfaces

After you enable NPV, you should configure the NP uplink interfaces and the server interfaces. To configure an NP uplink interface, perform this task:

Command

Purpose

Step 1

switch# configure terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

Selects an interface that will be connected to the core NPV switch.

Step 3

switch(config-if)# switchport mode NP

switch(config-if)# no shutdown

Configures the interface as an NP port.

Brings up the interface.

Command

Purpose

Step 1

switch# configure terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface {fc slot/port |

vfc vfc-id}

Step 3

switch(config-if)# switchport mode F

switch(config-if)# no shutdown

Configures the interface as an F port.

Brings up the interface.

Configuring NPV Traffic Management

After the interfaces are configured in NPV mode, you can configure NPV traffic management.

This section includes the following topics:

- Configuring NPV Traffic Maps

- Enabling Disruptive Load Balancing

Configuring NPV Traffic Maps

An NPV traffic map associates one or more NP uplink interfaces with a server interface. The switch associates the server interface with one of these NP uplinks.

Note If a server interface is already mapped to an NP uplink, you should include this mapping in the traffic map configuration.

switch# config t

switch(config)#

Enters configuration mode on the NPV.

Step 2

switch(config)# npv traffic-map server-interface {fc slot/port | vfc vfc-id} external-interface fc slot/port

switch (config)#

Configures a mapping between a server interface (or range of server interfaces) and an NP uplink interface (or range of NP uplink interfaces).

switch(config)# no npv traffic-map server-interface {fc slot/port | vfc vfc-id} external-interface fc slot/port

switch (config)#

Removes the mapping between the specified server interfaces and NP uplink interfaces.

Note The traffic map configuration only takes effect after you reinitialize each of the server interfaces specified in the map.

Enabling Disruptive Load Balancing

If you configure additional NP uplinks, you can enable the disruptive load-balancing feature to distribute the server traffic load evenly among all the NP uplinks.

To enable disruptive load balancing, perform this task:

Command

Purpose

Step 1

switch# configure terminal

switch(config)#

Enters configuration mode on the NPV.

Step 2

switch(config)# npv auto-load-balance

disruptive

switch (config)#

Enables disruptive load balancing on the switch.

Step 3

switch (config)# no npv auto-load-balance disruptive

Disables disruptive load balancing on the switch.

Note Enabling disruptive load balancing may force reinitialization of one or more server interfaces. This action causes traffic disruption to the attached devices.

Verifying NPV

Command

Purpose

switch# show npv flogi-table [all]

Displays the NPV configuration.

To display a list of devices on a server interface and their assigned NP uplinks, enter the show npv flogi-table command on the Cisco Nexus 5000 Series switch:

switch# show npv flogi-table

--------------------------------------------------------------------------------

SERVER EXTERNAL

INTERFACE VSAN FCID PORT NAME NODE NAME INTERFACE

--------------------------------------------------------------------------------

vfc3/1 1 0xee0008 10:00:00:00:c9:60:e4:9a 20:00:00:00:c9:60:e4:9a fc2/1

vfc3/1 1 0xee0009 20:00:00:00:0a:00:00:01 20:00:00:00:c9:60:e4:9a fc2/2

vfc3/1 1 0xee000a 20:00:00:00:0a:00:00:02 20:00:00:00:c9:60:e4:9a fc2/3

vfc3/1 1 0xee000b 33:33:33:33:33:33:33:33 20:00:00:00:c9:60:e4:9a fc2/4

Total number of flogi = 4

Note For each server interface, the External Interface value displays the assigned NP uplink.

core-switch# show fcns database detail

Verifying NPV Traffic Management

To display the disruptive load-balancing status, enter the show npv status command:

Configuring SAN Port Channels

SAN port channels refer to the aggregation of multiple physical interfaces into one logical interface to provide higher aggregated bandwidth, load balancing, and link redundancy.

On Cisco Nexus 5000 Series switches, SAN port channels can include physical Fibre Channel interfaces, but not virtual Fibre Channel interfaces. A SAN port channel can include up to eight Fibre Channel interfaces.

This chapter discusses the SAN port channel feature provided in the switch and includes the following sections:

- Information About SAN Port Channels

- Configuring SAN Port Channels

- Interfaces in a SAN Port Channel

- Port Channel Protocol

- Verifying SAN Port Channel Configuration

- Default Settings

Information About SAN Port Channels

A SAN port channel has the following functionality:

- Provides a point-to-point connection over ISL (E ports) or EISL (TE ports). Multiple links can be combined into a SAN port channel.

- Increases the aggregate bandwidth on an ISL by distributing traffic among all functional links in the channel.

- Load balances across multiple links and maintains optimum bandwidth utilization. Load balancing is based on the source ID, destination ID, and exchange ID (OX ID).

- Provides high availability on an ISL. If one link fails, traffic previously carried on this link is switched to the remaining links. If a link goes down in a SAN port channel, the upper layer protocol is not aware of it. To the upper layer protocol, the link is still there, although the bandwidth is diminished. The routing tables are not affected by link failure.

Cisco Nexus 5000 Series switches support a maximum of four SAN port channels (with eight interfaces per port channel). A port channel number refers to the unique (within each switch) identifier associated with each channel group. This number ranges from 1 to 256.

This section describes SANs and includes the following topics:

- Understanding Port Channels and VSAN Trunking

- Understanding Load Balancing

Understanding Port Channels and VSAN Trunking

Switches in the Cisco Nexus 5000 Series implement VSAN trunking and port channels as follows:

- A SAN port channel enables several physical links to be combined into one aggregated logical link.

- An industry standard E port can link to other vendor switches and is referred to as inter-switch link (ISL), as shown on the left side of Figure 1-1.

- VSAN trunking enables a link transmitting frames in the EISL format to carry traffic for multiple VSAN . When trunking is operational on an E port, that E port becomes a TE port. EISLs connects only between Cisco switches, as shown on the right side of Figure 1-1.

See Chapter 1, “Configuring VSAN Trunking” for information on trunk interfaces.

Figure 1-1 VSAN Trunking Only

You can create a SAN port channel with members that are E ports, as shown on the left side of Figure 1-2. In this configuration, the port channel implements a logical ISL (carrying traffic for one VSAN).

You can create a SAN port channel with members that are TE-ports, as shown on the right side of Figure 1-2. In this configuration, the port channel implements a logical EISL (carrying traffic for multiple VSANs).

Figure 1-2 Port Channels and VSAN Trunking

Understanding Load Balancing

Load-balancing functionality can be provided using the following methods:

- Flow based—All frames between source and destination follow the same links for a given flow. That is, whichever link is selected for the first exchange of the flow is used for all subsequent exchanges.

- Exchange based—The first frame in an exchange is assigned to a link, and then subsequent frames in the exchange follow the same link. However, subsequent exchanges can use a different link. This method provides finer granularity for load balancing while preserving the order of frames for each exchange.

Figure 1-3 illustrates how flow-based load balancing works. When the first frame in a flow is received on an interface for forwarding, link 1 is selected. Each subsequent frame in that flow is sent over the same link. No frame in SID1 and DID1 utilizes link 2.

Figure 1-3 SID1, DID1, and Flow-Based Load Balancing

Figure 1-4 illustrates how exchange-based load balancing works. When the first frame in an exchange is received for forwarding on an interface, link 1 is chosen by a hash algorithm. All remaining frames in that particular exchange are sent on the same link. For exchange 1, no frame uses link 2. For the next exchange, link 2 is chosen by the hash algorithm. Now all frames in exchange 2 use link 2.

Figure 1-4 SID1, DID1, and Exchange-Based Load Balancing

Configuring SAN Port Channels

SAN port channels are created with default values. You can change the default configuration just as any other physical interface.

Figure 1-5 provides examples of valid SAN port channel configurations.

Figure 1-5 Valid SAN Port Channel Configurations

Figure 1-6 shows examples of invalid configurations. Assuming that the links are brought up in the 1, 2, 3, 4 sequence, links 3 and 4 will be operationally down as the fabric is misconfigured.

Figure 1-6 Misconfigured Configurations

This section shows how to configure and modify SAN port channels and includes the following topics:

- SAN Port Channel Configuration Guidelines

- Creating a SAN Port Channel

- About SAN Port Channel Modes

- About SAN Port Channel Deletion

- Deleting SAN Port Channels

SAN Port Channel Configuration Guidelines

Before configuring a SAN port channel, consider the following guidelines:

- Configure the SAN port channel using Fibre Channel ports from both expansion modules to provide increased availability (if one of the expansion modules failed).

- Ensure that one SAN port channel is not connected to different sets of switches. SAN port channels require point-to-point connections between the same set of switches.

If you misconfigure SAN port channels, you may receive a misconfiguration message. If you receive this message, the port channel’s physical links are disabled because an error has been detected.

If the following requirements are not met, a SAN port channel error is detected:

- Each switch on either side of a SAN port channel must be connected to the same number of interfaces.

- Each interface must be connected to a corresponding interface on the other side (see Figure 1-6 for an example of an invalid configuration).

- Links in a SAN port channel cannot be changed after the port channel is configured. If you change the links after the port channel is configured, be sure to reconnect the links to interfaces within the port channel and reenable the links.

If all three conditions are not met, the faulty link is disabled.

Enter the show interface command for that interface to verify that the SAN port channel is functioning as required.

Creating a SAN Port Channel

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface san-port-channel channel-number

Creates the specified SAN port channel using the default mode (on). The SAN port channel number is in the range of 1 to 256.

The following example shows SAN port channel creation:

switch(config)# interface san-port-channel 1

switch(config-if)#

About SAN Port Channel Modes

You can configure each SAN port channel with a channel group mode parameter to determine the port channel protocol behavior for all member ports in this channel group. The possible values for a channel group mode are as follows:

- On (default)—The member ports only operate as part of a SAN port channel or remain inactive. In this mode, the port channel protocol is not initiated. However, if a port channel protocol frame is received from a peer port, the software indicates its nonnegotiable status. Port channels configured in the On mode require you to explicitly enable and disable the port channel member ports at either end if you add or remove ports from the port channel configuration. You must physically verify that the local and remote ports are connected to each other.

- Active—The member ports initiate port channel protocol negotiation with the peer port(s) regardless of the channel group mode of the peer port. If the peer port, while configured in a channel group, does not support the port channel protocol, or responds with a nonnegotiable status, it will default to the On mode behavior. The Active port channel mode allows automatic recovery without explicitly enabling and disabling the port channel member ports at either end.

Table 1-1 compares On and Active modes.

Table 1-1 Channel Group Configuration Differences

On Mode

Active Mode

No protocol is exchanged.

A port channel protocol negotiation is performed with the peer ports.

Moves interfaces to the suspended state if its operational values are incompatible with the SAN port channel.

Moves interfaces to the isolated state if its operational values are incompatible with the SAN port channel.

When you add or modify a port channel member port configuration, you must explicitly disable (shut) and enable (no shut) the port channel member ports at either end.

When you add or modify a port channel interface, the SAN port channel automatically recovers.

Port initialization is not synchronized.

There is synchronized startup of all ports in a channel across peer switches.

All misconfigurations are not detected as no protocol is exchanged.

Consistently detect misconfigurations using a port channel protocol.

Transitions misconfigured ports to the suspended state. You must explicitly disable (shut) and enable (no shut) the member ports at either end.

Transitions misconfigured ports to the isolated state to correct the misconfiguration. Once you correct the misconfiguration, the protocol ensures automatic recovery.

This is the default mode.

You must explicitly configure this mode.

To configure active mode, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface san-port-channel channel-number

switch(config-if)#

Configures the specified port channel using the default On mode. The SAN port channel number is in the range of 1 to 256.

Step 3

switch(config-if)# channel mode active

Configures the Active mode.

switch(config-if)# no channel mode active

Reverts to the default On mode.

The following example shows how to configure active mode:

switch(config)# interface san-port-channel 1

switch(config-if)# channel mode active

About SAN Port Channel Deletion

When you delete the SAN port channel, the corresponding channel membership is also deleted. All interfaces in the deleted SAN port channel convert to individual physical links. After the SAN port channel is removed, regardless of the mode (active and on) used, the ports at either end are gracefully brought down, indicating that no frames are lost when the interface is going down (see the “Setting the Interface Administrative State” section).

If you delete the SAN port channel for one port, then the individual ports within the deleted SAN port channel retain the compatibility parameter settings (speed, mode, port VSAN, allowed VSAN, and port security). You can explicitly change those settings as required.

- If you use the default On mode to avoid inconsistent states across switches and to maintain consistency across switches, then the ports shut down. You must explicitly enable those ports again.

- If you use the Active mode, then the port channel ports automatically recover from the deletion.

Deleting SAN Port Channels

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# no interface san-port-channel channel-number

Deletes the specified port channel, its associated interface mappings, and the hardware associations for this SAN port channel.

The following example shows SAN port channel deletion:

switch(config)# no interface san-port-channel 1

san-port-channel 1 deleted and all its members disabled

please do the same operation on the switch at the other end of the san-port-channel

Interfaces in a SAN Port Channel

You can add or remove a physical Fibre Channel interface (or a range of interfaces) to an existing SAN port channel. The compatible parameters on the configuration are mapped to the SAN port channel. Adding an interface to a SAN port channel increases the channel size and bandwidth of the SAN port channel. Removing an interface from a SAN port channel decreases the channel size and bandwidth of the SAN port channel.

Note Virtual Fibre Channel interfaces cannot be added to SAN port channels.

This section describes interface configuration for a SAN port channel and includes the following topics:

- About Interface Addition to a SAN Port Channel

- Adding an Interface to a SAN Port Channel

- Forcing an Interface Addition

- About Interface Deletion from a SAN Port Channel

- Deleting an Interface from a SAN Port Channel

About Interface Addition to a SAN Port Channel

You can add a physical interface (or a range of interfaces) to an existing SAN port channel. The compatible parameters on the configuration are mapped to the SAN port channel. Adding an interface to a SAN port channel increases the channel size and bandwidth of the SAN port channel.

After the members are added, regardless of the mode (Active and On) used, the ports at either end are gracefully brought down, indicating that no frames are lost when the interface is going down.

Compatibility Check

A compatibility check ensures that the same parameter settings are used in all physical ports in the channel. Otherwise, they cannot become part of a SAN port channel. The compatibility check is performed before a port is added to the SAN port channel.

The check ensures that the following parameters and settings match at both ends of a SAN port channel:

- Capability parameters (type of interface, Fibre Channel at both ends).

- Administrative compatibility parameters (speed, mode, port VSAN, allowed VSAN, and port security).

- Operational parameters (speed and remote switch’s WWN).

A port addition procedure fails if the capability and administrative parameters in the remote switch are incompatible with the capability and administrative parameters in the local switch. If the compatibility check is successful, the interfaces are operational and the corresponding compatibility parameter settings apply to these interfaces.

Suspended and Isolated States

If the operational parameters are incompatible, the compatibility check fails and the interface is placed in a suspended or isolated state based on the configured mode:

- An interface enters the suspended state if the interface is configured in the On mode.

- An interface enters the isolated state if the interface is configured in the Active mode.

See the “Reason Codes” section.

Adding an Interface to a SAN Port Channel

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

switch(config-if)#

Enters configuration mode for the specified interface.

Step 3

switch(config-if)# channel-group channel-number

Adds the Fibre Channel interface to the specified channel group. If the channel group does not exist, it is created. The port is shut down.

The following example adds an interface to a SAN port channel:

switch(config)# interface fc2/3

switch(config-if)# channel-group 15

fc2/3 added to san-port-channel 15 and disabled

please do the same operation on the switch at the other end of the san-port-channel, then do “no shutdown” at both ends to bring them up

Forcing an Interface Addition

You can force the port configuration to be overwritten by the SAN port channel. In this case, the interface is added to a SAN port channel.

- If you use the default On mode to avoid inconsistent states across switches and to maintain consistency across switches, then the ports shut down. You must explicitly enable those ports again.

- If you use the Active mode, then the port channel ports automatically recover from the addition.

Note When SAN port channels are created from within an interface, the force option cannot be used.

After the members are forcefully added, regardless of the mode (Active and On) used, the ports at either end are gracefully brought down, indicating that no frames are lost when the interface is going down (see the “Setting the Interface Administrative State” section).

To force the addition of a port to a SAN port channel, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

switch(config-if)#

Enters configuration mode for the specified interface.

Step 3

switch(config-if)# channel-group channel-number force

Forces the addition of the interface into the specified channel group. The E port is shut down.

The following example adds an interface to a SAN port channel:

switch(config)# interface fc2/3

switch(config-if)# channel-group 15 force

fc2/3 added to san-port-channel 15 and disabled

please do the same operation on the switch at the other end of the san-port-channel, then do “no shutdown” at both ends to bring them up

About Interface Deletion from a SAN Port Channel

When a physical interface is deleted from the SAN port channel, the channel membership is automatically updated. If the deleted interface is the last operational interface, then the port channel status is changed to a down state. Deleting an interface from a SAN port channel decreases the channel size and bandwidth of the SAN port channel.

- If you use the default On mode to avoid inconsistent states across switches and to maintain consistency across switches, then the ports shut down. You must explicitly enable those ports again.

- If you use the Active mode, then the port channel ports automatically recover from the deletion.

After the members are deleted, regardless of the mode (Active and On) used, the ports at either end are gracefully brought down, indicating that no frames are lost when the interface is going down.

Deleting an Interface from a SAN Port Channel

switch(config)# interface type slot/port

Enters configuration mode for the specified interface.

Step 2

switch(config-if)# no channel-group channel-number

Deletes the physical Fibre Channel interface from the specified channel group.

The following example deletes an interface from a SAN port channel:

switch(config)# interface fc2/3

switch(config-if)# no channel-group 15

fc2/1 removed from san-port-channel 2 and disabled. Please do the same operation on the switch at the other end of the san-port-channel

Port Channel Protocol

The switch software provides robust error detection and synchronization capabilities. You can manually configure channel groups, or they can be automatically created. In both cases, the channel groups have the same capability and configurational parameters. Any change in configuration applied to the associated port channel interface is propagated to all members of the channel group.

Cisco SAN switches support a protocol to exchange port channel configurations, which simplifies port channel management with incompatible ISLs. An additional autocreation mode enables ISLs with compatible parameters to automatically form channel groups without manual intervention.

The port channel protocol is enabled by default.

The port channel protocol expands the port channel functional model in Cisco SAN switches. It uses the exchange peer parameters (EPP) services to communicate across peer ports in an ISL. Each switch uses the information received from the peer ports along with its local configuration and operational values to decide if it should be part of a SAN port channel. The protocol ensures that a set of ports are eligible to be part of the same SAN port channel. They are only eligible to be part of the same port channel if all the ports have a compatible partner.

The port channel protocol uses two subprotocols:

- Bringup protocol—Automatically detects misconfigurations so you can correct them. This protocol synchronizes the SAN port channel at both ends so that all frames for a given flow (as identified by the source FC ID, destination FC ID and OX_ID) are carried over the same physical link in both directions. This helps make applications such as write acceleration work for SAN port channels over FCIP links.

- Autocreation protocol—Automatically aggregates compatible ports into a SAN port channel.

This section describes how to configure the port channel protocol and includes the following sections:

- About Channel Group Creation

- Autocreation Guidelines

- Enabling and Configuring Autocreation

- About Manually Configured Channel Groups

- Converting to Manually Configured Channel Groups

About Channel Group Creation

If channel group autocreation is enabled, ISLs can be configured automatically into channel groups without manual intervention. Figure 1-7 shows an example of channel group autocreation.

The first ISL comes up as an individual link. In the example shown in Figure 1-7, this is link A1-B1. When the next link comes up (A2-B2 in the example), the port channel protocol determines if this link is compatible with link A1-B1 and automatically creates channel groups 10 and 20 in the respective switches. Link A3-B3 can join the channel groups (and the port channels) if the respective ports have compatible configurations. Link A4-B4 operates as an individual link, because it is not compatible with the existing member ports in the channel group.

Figure 1-7 Autocreating Channel Groups

The channel group numbers are assigned dynamically (when the channel group is formed).

The channel group number may change across reboots for the same set of port channels depending on the initialization order of the ports.

Table 1-2 Channel Group Configuration Differences

User-Configured Channel Group

Autocreated Channel Group

Manually configured by the user.

Created automatically when compatible links come up between two compatible switches, if channel group autocreation is enabled in all ports at both ends.

Member ports cannot participate in autocreation of channel groups. The autocreation feature cannot be configured.

None of these ports are members of a user-configured channel group.

You can form the SAN port channel with a subset of the ports in the channel group. Incompatible ports remain in a suspended or isolated state depending on the On or Active mode configuration.

All ports included in the channel group participate in the SAN port channel. No member port becomes isolated or suspended; instead, the member port is removed from the channel group when the link is found to be incompatible.

Any administrative configuration made to the SAN port channel is applied to all ports in the channel group, and you can save the configuration for the port channel interface.

Any administrative configuration made to the SAN port channel is applied to all ports in the channel group, but the configurations are saved for the member ports; no configuration is saved for the port channel interface. You can explicitly convert this channel group, if required.

You can remove any channel group and add members to a channel group.

You cannot remove a channel group. You cannot add members to the channel group or remove members. The channel group is removed when no member ports exist.

Autocreation Guidelines

When using the autocreation protocol, follow these guidelines:

- A port is not allowed to be configured as part of a SAN port channel when the autocreation feature is enabled. These two configurations are mutually exclusive.

- Autocreation must be enabled in both the local and peer ports to negotiate a SAN port channel.

- Aggregation occurs in one of two ways:

– A port is aggregated into a compatible autocreated SAN port channel.

– A port is aggregated with another compatible port to form a new SAN port channel.

- Newly created SAN port channels are allocated from the maximum possible port channel number in a decreasing order based on availability. If all port channel numbers are used up, aggregation is not allowed.

- You cannot change the membership or delete an autocreated SAN port channel.

- When you disable autocreation, all member ports are removed from the autocreated SAN port channel.

- Once the last member is removed from an autocreated SAN port channel, the channel is automatically deleted and the number is released for reuse.

- An autocreated SAN port channel is not persistent through a reboot. An autocreated SAN port channel can be manually configured to appear the same as a persistent SAN port channel. Once the SAN port channel is made persistent, the autocreation feature is disabled in all member ports.

- You can enable or disable the autocreation feature on a per-port basis or for all ports in the switch. When this configuration is enabled, the channel group mode is assumed to be active. The default for this task is disabled.

- If autocreation of channel groups is enabled for an interface, you must first disable autocreation before downgrading to earlier software versions or before configuring the interface in a manually configured channel group.

Tip When enabling autocreation in any switch in the Cisco Nexus 5000 Series, we recommend that you retain at least one interconnected port between the switches without any autocreation configuration. If all ports between two switches are configured with the autocreation feature at the same time, a possible traffic disruption may occur between these two switches as ports are automatically disabled and reenabled when they are added to an autocreated SAN port channel.

Enabling and Configuring Autocreation

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# interface type slot/port

switch(config-if)#

Enters configuration mode for the specified interface.

Step 3

switch(config- if)# channel-group auto

Automatically creates the channel group for the selected interface(s).

switch(config- if)# no channel-group auto

Disables the autocreation of channel groups for this interface, even if the system default configuration may have autocreation enabled.

The following example configures an automatic channel group:

switch(config)# interface fc2/3

switch(config-if)# channel-group auto

About Manually Configured Channel Groups

A user-configured channel group cannot be converted to an autocreated channel group. However, you can convert an autocreated channel group to a manual channel group. This task is irreversible. The channel group number does not change, but the member ports operate according to the properties of the manually configured channel group, and channel group autocreation is implicitly disabled for all the member ports.

Tip If you enable persistence, be sure to enable it at both ends of the SAN port channel.

Converting to Manually Configured Channel Groups

You can convert autocreated channel group to a user-configured channel group using the san-port-channel channel-group-number persistent EXEC command. If the SAN port channel does not exist, this command is not executed.

Verifying SAN Port Channel Configuration

You can view specific information about existing SAN port channels at any time from EXEC mode. The following show commands provide further details on existing SAN port channels.

The show san-port-channel summary command displays a summary of SAN port channels within the switch. A one-line summary of each SAN port channel provides the administrative state, the operational state, the number of attached and active interfaces (up), and the first operational port (FOP), which is the primary operational interface selected in the SAN port channel to carry control-plane traffic (no load-balancing). The FOP is the first port that comes up in a SAN port channel and can change if the port goes down. The FOP is also identified by an asterisk ( * ).

To display VSAN configuration information, perform one of the following tasks:

Command

Purpose

switch# show san-port-channel summary | database | consistency [ details ] | usage | compatibility-parameters

Displays SAN port channel information.

switch# show san-port-channel database interface san-port-channel channel-number

Displays information for the specified SAN port channel.

switch# show interface fc slot/port

Displays VSAN configuration information for the specified Fibre Channel interface.

The following example shows how to display a summary of SAN port channel information:

switch# show san-port-channel summary

------------------------------------------------------------------------------

Interface Total Ports Oper Ports First Oper Port

------------------------------------------------------------------------------

san-port-channel 7 2 0 --

san-port-channel 8 2 0 --

san-port-channel 9 2 2

The following example shows how to display SAN port channel consistency:

switch# show san-port-channel consistency

Database is consistent

The following example shows how to display details of the used and unused port channel numbers:

switch# show san-port-channel usage

Totally 3 port-channel numbers used

===================================

Used : 77 - 79

Unused: 1 - 76 , 80 - 256

Autocreated SAN port channels are indicated explicitly to help differentiate them from the manually created SAN port channels. The following example shows how to display an autocreated port channel:

switch# show interface fc2/1

fc2/1 is trunking

Hardware is Fibre Channel, FCOT is short wave laser

Port WWN is 20:0a:00:0b:5f:3b:fe:80

...

Receive data field Size is 2112

Beacon is turned off

Port-channel auto creation is enabled

Belongs to port-channel 123

...

Default Settings

Table 1-3 Default SAN Port Channel Parameters

Parameters

Default

Port channels

FSPF is enabled by default.

Create port channel

Administratively up.

Default port channel mode

On.

Autocreation

Configuring RADIUS

This chapter describes how to configure Remote Access Dial-In User Service (RADIUS) protocol on the Nexus 5000 Series switch.

This chapter includes the following sections:

- Information About RADIUS

- Prerequisites for RADIUS

- Guidelines and Limitations

- Configuring RADIUS Servers

- The following example shows how to manually send a test message to a RADIUS server:

- Displaying RADIUS Server Statistics

- Example RADIUS Configuration

- Default Settings

Information About RADIUS

The RADIUS distributed client/server system allows you to secure networks against unauthorized access. In the Cisco implementation, RADIUS clients run on the Nexus 5000 Series of switches and send authentication and accounting requests to a central RADIUS server that contains all user authentication and network service access information.

This section includes the following topics:

- RADIUS Network Environments

- RADIUS Operation

- Vendor-Specific Attributes

RADIUS Network Environments

RADIUS can be implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.

You can use RADIUS in the following network environments that require access security:

- Networks with multiple-vendor network devices, each supporting RADIUS.

For example, network devices from several vendors can use a single RADIUS server-based security database.

- Networks already using RADIUS.

You can add a Nexus 5000 Series switch with RADIUS to the network. This action might be the first step when you make a transition to a AAA server.

- Networks that require resource accounting.

You can use RADIUS accounting independent of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, indicating the amount of resources (such as time, packets, bytes, and so on) used during the session. An Internet service provider (ISP) might use a freeware-based version of the RADIUS access control and accounting software to meet special security and billing needs.

- Networks that support authentication profiles.

Using the RADIUS server in your network, you can configure AAA authentication and set up per-user profiles. Per-user profiles enable the Nexus 5000 Series switch to better manage ports using their existing RADIUS solutions and to efficiently manage shared resources to offer different service-level agreements.

RADIUS Operation

When a user attempts to log in and authenticate to a Nexus 5000 Series switch using RADIUS, the following process occurs:

1. The user is prompted for and enters a username and password.

2. The username and encrypted password are sent over the network to the RADIUS server.

3. The user receives one of the following responses from the RADIUS server:

- ACCEPT—The user is authenticated.

- REJECT—The user is not authenticated and is prompted to reenter the username and password, or access is denied.

- CHALLENGE—A challenge is issued by the RADIUS server. The challenge collects additional data from the user.

- CHANGE PASSWORD—A request is issued by the RADIUS server, asking the user to select a new password.

The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or network authorization. You must first complete RADIUS authentication before using RADIUS authorization. The additional data included with the ACCEPT or REJECT packets consists of the following:

- Services that the user can access, including Telnet, rlogin, or local-area transport (LAT) connections, and Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services.

- Connection parameters, including the host or client IPv4 or IPv6 address, access list, and user timeouts.

RADIUS Server Monitoring

An unresponsive RADIUS server can cause delay in processing of AAA requests. You can configure the Nexus 5000 Series switch to periodically monitor a RADIUS server to check whether it is responding (or alive) to save time in processing AAA requests. The Nexus 5000 Series switch marks unresponsive RADIUS servers as dead and does not send AAA requests to any dead RADIUS servers. The switch periodically monitors the dead RADIUS servers and brings them to the alive state once they respond. This monitoring process verifies that a RADIUS server is in a working state before real AAA requests are sent its way. Whenever a RADIUS server changes to the dead or alive state, a Simple Network Management Protocol (SNMP) trap is generated and the Nexus 5000 Series switch displays an error message that a failure is taking place. See Figure 1-1.

Figure 1-1 RADIUS Server States

Note The monitoring interval for alive servers and dead servers are different and can be configured by the user. The RADIUS server monitoring is performed by sending a test authentication request to the RADIUS server.

Vendor-Specific Attributes

When you use RADIUS servers for authentication on a Nexus 5000 Series switch, the RADIUS protocol directs the RADIUS server to return user attributes, such as authorization information, along with authentication results. This authorization information is specified through VSAs.

The following VSA protocol options are supported by the Nexus 5000 Series switch:

- Shell— Used in access-accept packets to provide user profile information.

- Accounting— Used in accounting-request packets. If a value contains any white spaces, you should enclose the value within double quotation marks.

The Nexus 5000 Series switch supports the following attributes:

- roles—Lists all the roles to which the user belongs. The value field is a string that lists the role names delimited by white space.

- accountinginfo—Stores accounting information in addition to the attributes covered by a standard RADIUS accounting protocol. This attribute is sent only in the VSA portion of the Account-Request frames from the RADIUS client on the switch. It can be used only with the accounting protocol data units (PDUs).

Prerequisites for RADIUS

RADIUS has the following prerequisites:

- Obtain IPv4 or IPv6 addresses or host names for the RADIUS servers.

- Obtain preshared keys from the RADIUS servers.

- Ensure that the Nexus 5000 Series switch is configured as a RADIUS client of the AAA servers.

Guidelines and Limitations

RADIUS has the following guidelines and limitations:

- You can configure a maximum of 64 RADIUS servers on the Nexus 5000 Series switch.

Configuring RADIUS Servers

To configure RADIUS servers, perform this task:

Step 1 Establish the RADIUS server connections to the Nexus 5000 Series switch.

See the “Configuring RADIUS Server Hosts” section.

Step 2 Configure the preshared secret keys for the RADIUS servers.

See the “Configuring Global Preshared Keys” section.

Step 3 If needed, configure RADIUS server groups with subsets of the RADIUS servers for AAA authentication methods.

See the “Allowing Users to Specify a RADIUS Server at Login” section and the “Configuring AAA” section.

Step 4 If needed, configure any of the following optional parameters:

- Dead-time interval

See the “The following example shows how to configure periodic RADIUS server monitoring:” section.

- Allow specification of a RADIUS server at login

See the “Allowing Users to Specify a RADIUS Server at Login” section).

- Transmission retry count and timeout interval

See the “Configuring the Global RADIUS Transmission Retry Count and Timeout Interval” section.

- Accounting and authentication attributes

See the “Configuring Accounting and Authentication Attributes for RADIUS Servers” section.

Step 5 If needed, configure periodic RADIUS server monitoring.

See the “Configuring Periodic RADIUS Server Monitoring” section.

The following topics describe the RADIUS configuration procedure in more details:

- Configuring RADIUS Server Hosts

- Configuring Global Preshared Keys

- Configuring RADIUS Server Preshared Keys

- Configuring RADIUS Server Groups

- Allowing Users to Specify a RADIUS Server at Login

- Configuring the Global RADIUS Transmission Retry Count and Timeout Interval

- Configuring the RADIUS Transmission Retry Count and Timeout Interval for a Server

- Configuring Accounting and Authentication Attributes for RADIUS Servers

- Configuring Periodic RADIUS Server Monitoring

- Configuring the Dead-Time Interval

- Manually Monitoring RADIUS Servers or Groups

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Configuring RADIUS Server Hosts

You must configure the IPv4 or IPv6 address or the host name for each RADIUS server that you want to use for authentication. All RADIUS server hosts are added to the default RADIUS server group. You can configure up to 64 RADIUS servers.

To configure a RADIUS server host, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config) #radius-server host {ipv4-address | ipv6-address | host-name}

Specifies the IPv4 or IPv6 address or hostname for a RADIUS server.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure a RADIUS server host:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

To configure global preshared keys, obtain the preshared key values for the remote RADIUS servers and perform this task:

:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# radius-server key [0 | 7] key-value

Specifies a preshared key for all RADIUS servers. You can specify a clear text (0) or encrypted (7) preshared key. The default format is clear text. The maximum length is 63 characters.

By default, no preshared key is configured.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show radius-server

(Optional) Displays the RADIUS server configuration.
command to display the encrypted preshared keys.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to obtain the preshared key values for a remote RADIUS server:

switch# configure terminal

switch(config)# radius-server key 0 QsEfThUkO

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring RADIUS Server Preshared Keys

You can configure preshared keys for a RADIUS server. A preshared key is a shared secret text string between the Nexus 5000 Series switch and the RADIUS server host.

To configure radius server preshared keys, obtain the preshared key values for the remote RADIUS servers and perform this task:

:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# radius-server host {ipv4-address | ipv6-address | host-name} key [0 | 7] key-value

Specifies a preshared key for a specific RADIUS server. You can specify a clear text (0) or encrypted (7) preshared key. The default format is clear text. The maximum length is 63 characters.

This preshared key is used instead of the global preshared key.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show radius-server

(Optional) Displays the RADIUS server configuration.
command to display the encrypted preshared keys.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure a preshared keys for a RADIUS server:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 key 0 PlIjUhYg

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring RADIUS Server Groups

You can specify one or more remote AAA servers for authentication using server groups. All members of a group must belong to the RADIUS protocol. The servers are tried in the same order in which you configure them.

You can configure these server groups at any time but they only take effect when you apply them to an AAA service. For information on AAA services, see the “Remote AAA Services” section.

To configure radius server groups, perform this task:

:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa group server radius group-name

Creates a RADIUS server group and enters the RADIUS server group configuration submode for that group. The group-name argument is a case-sensitive alphanumeric string with a maximum length of 127 characters.

Step 3

switch(config-radius)# server {ipv4-address |ipv6-address | server-name}

Configures the RADIUS server as a member of the RADIUS server group.
command and retry this command.

Step 4

switch(config-radius)# deadtime minutes

(Optional) Configures the monitoring dead time. The default is 0 minutes. The range is from 1 through 1440.

Note If the dead-time interval for a RADIUS server group is greater than zero (0), that value takes precedence over the global dead-time value. See the example that shows how to configure periodic RADIUS server monitoring.

Step 5

switch(config-radius)# exit

Exits configuration mode.

Step 6

switch(config) #show radius-server group [GROUP-NAME]

(Optional) Displays the RADIUS server group configuration.

Step 7

switch(config)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure a RADIUS server group:

switch# configure terminal

switch(config)# aaa group server radius RadServer

switch(config-radius)# server 10.10.1.1

switch(config-radius)# deadtime 30

switch(config-radius)# use-vrf management

switch(config-radius)# exit

switch(config)# show radius-server group

switch(config)# copy running-config startup-config

Allowing Users to Specify a RADIUS Server at Login

Note By default, the Nexus 5000 Series switch forwards an authentication request based on the default AAA authentication method. You can configure the Nexus 5000 Series switch to allow the user to specify a VRF and RADIUS server to send the authenticate request by enabling the directed-request option. If you enable this option, the user can log in as username@hostname, where hostname is the name of a configured RADIUS server. User specified logins are only supported for Telnet sessions.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# switch(config)# radius-server directed-request

Allows users to specify a RADIUS server to send the authentication request when logging in. The default is disabled.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show radius-server directed-request

(Optional) Displays the directed request configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring the Global RADIUS Transmission Retry Count and Timeout Interval

You can configure a global retransmission retry count and timeout interval for all RADIUS servers. By default, a switch retries transmission to a RADIUS server only once before reverting to local authentication. You can increase this number up to a maximum of five retries per server. The timeout interval determines how long the Nexus 5000 Series switch waits for responses from RADIUS servers before declaring a timeout failure.

To configure the global RADIUS transmission retry count and timeout interval, perform this task:

:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# radius-server retransmit count

Specifies the retransmission count for all RADIUS servers. The default retransmission count is 1 and the range is from 0 to 5.

Step 3

switch(config)# radius-server timeout seconds

Specifies the transmission timeout interval for RADIUS servers. The default timeout interval is 5 seconds and the range is from 1 to 60 seconds.

Step 4

switch(config)# exit

Exits configuration mode.

Step 5

switch# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 6

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring the RADIUS Transmission Retry Count and Timeout Interval for a Server

By default, a Nexus 5000 Series switch retries transmission to a RADIUS server only once before reverting to local authentication. You can increase this number up to a maximum of five retries per server. You can also set a timeout interval that the Nexus 5000 Series switch waits for responses from RADIUS servers before declaring a timeout failure.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

#switch(config)# radius-server host {ipv4-address |ipv6-address | host-name} retransmit count

Specifies the retransmission count for a specific server. The default is the global value.

Note The retransmission count value specified for a RADIUS server overrides the count specified for all RADIUS servers in Step 2.

Step 3

switch(config)# switch(config)# radius-server host {ipv4-address |ipv6-address | host-name} timeout seconds

Specifies the transmission timeout interval for a specific server. The default is the global value.

Note The timeout interval value specified for a RADIUS server overrides the interval value specified for all RADIUS servers in Step 3.

Step 4

switch(config)# exit

Exits configuration mode.

Step 5

switch# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 6

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure RADIUS transmission retry count and timeout interval for a server:

switch# configure terminal

switch(config)# radius-server host server1 retransmit 3

switch(config)# radius-server host server1 timeout 10

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring Accounting and Authentication Attributes for RADIUS Servers

You can specify that a RADIUS server is to be used only for accounting purposes or only for authentication purposes. By default, RADIUS servers are used for both accounting and authentication. You can also specify the destination UDP port numbers where RADIUS accounting and authentication messages should be sent.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config) #radius-server host {ipv4-address | ipv6-address | host-name} acct-port udp-port

(Optional) Specifies a UDP port to use for RADIUS accounting messages.The default UDP port is 1812. The range is from 0 to 65535.

Step 3

switch(config)# radius-server host {ipv4-address | ipv6-address | host-name} accounting

(Optional) Specifies that the specified RADIUS server it to be used only for accounting purposes. The default is both accounting and authentication.

Step 4

switch(config)# radius-server host {ipv4-address | ipv6-address | host-name} auth-port udp-port

Step 5

switch(config)# radius-server host {ipv4-address | ipv6-address | host-name} authentication

(Optional) Specifies that the specified RADIUS server only be used for authentication purposes. The default is both accounting and authentication.

Step 6

switch(config)# exit

Exits configuration mode.

Step 7

switch(config)# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 8

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure the accounting and authentication attributes for a RADIUS server:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 acct-port 2004

switch(config)# radius-server host 10.10.1.1 accounting

switch(config)# radius-server host 10.10.2.2 auth-port 2005

switch(config)# radius-server host 10.10.2.2 authentication

switch(config)# exit

switch(config)# show radius-server

switch# copy running-config startup-config

Configuring Periodic RADIUS Server Monitoring

You can monitor the availability of RADIUS servers. These parameters include the username and password to use for the server and an idle timer. The idle timer specifies the interval during which a RADIUS server receives no requests before the Nexus 5000 Series switch sends out a test packet. You can configure this option to test servers periodically.

Note For security reasons, we recommend that you do not configure a test username that is the same as an existing user in the RADIUS database.

The test idle timer specifies the interval during which a RADIUS server receives no requests before the Nexus 5000 Series switch sends out a test packet.

Note The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, the Nexus 5000 Series switch does not perform periodic RADIUS server monitoring.

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# radius-server host {ipv4-address | ipv6-address | host-name} test {idle-time minutes | password password [idle-time minutes] | username name [password password [idle-time minutes]]}

Specifies parameters for server monitoring. The default username is test and the default password is test. The default value for the idle timer is 0 minutes. The valid range is 0 to 1440 minutes.

Note For periodic RADIUS server monitoring, you must set the idle timer to a value greater than 0.

Step 3

switch(config)# radius-server deadtime minutes

Specifies the number of minutes before the Nexus 5000 Series switch checks a RADIUS server that was previously unresponsive. The default value is 0 minutes. The valid range is 1 to 1440 minutes.

Step 4

switch(config)# exit

Exits configuration mode.

Step 5

switch# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 6

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure periodic RADIUS server monitoring:

switch# configure terminal

switch(config)# radius-server host 10.10.1.1 test username user1 password Ur2Gd2BH idle-time 3

switch(config)# radius-server deadtime 5

switch(config)# exit

switch# show radius-server

switch# copy running-config startup-config

Configuring the Dead-Time Interval

You can configure the dead-time interval for all RADIUS servers. The dead-time interval specifies the time that the Nexus 5000 Series switch waits after declaring a RADIUS server is dead, before sending out a test packet to determine if the server is now alive. The default value is 0 minutes.

Note When the dead-time interval is 0 minutes, RADIUS servers are not marked as dead even if they are not responding. You can configure the dead-time interval for a RADIUS server group (see the “Configuring RADIUS Server Groups” section).

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

#switch(config)# radius-server deadtime

Configures the dead-time interval. The default value is 0 minutes. The range is from 1 to 1440 minutes.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show radius-server

(Optional) Displays the RADIUS server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Manually Monitoring RADIUS Servers or Groups

To manually send a test message to a RADIUS server or to a server group, perform this task:

Command

Purpose

Step 1

switch# test aaa server radius {ipv4-address | ipv6-address | server-name} [vrf vrf-name] username password

Sends a test message to a RADIUS server to confirm availability.

Step 1

switch# test aaa group group-name username password

Sends a test message to a RADIUS server group to confirm availability.

The following example shows how to manually send a test message to a RADIUS server:

switch# test aaa server radius 10.10.1.1 user1 Ur2Gd2BH

switch# test aaa group RadGroup user2 As3He3CI

Verifying RADIUS Configuration

To display RADIUS configuration information, perform one of the following tasks:

Command

Purpose

show running-config radius [all]

Displays the RADIUS configuration in the running configuration.

show startup-config radius

Displays the RADIUS configuration in the startup configuration.

show radius-server [server-name | ipv4-address | ipv6-address] [directed-request | groups | sorted | statistics]

Displays all configured RADIUS server parameters.

For detailed information about the fields in the output from this command, refer to the Cisco Nexus 5000 Series Command Reference.

Displaying RADIUS Server Statistics

To display the statistics the Cisco Nexus 5000 Series switch maintains for RADIUS server activity, perform this task:

Command

Purpose

Step 1

switch# switch# show radius-server statistics {hostname | ipv4-address | ipv6-address}

Displays the RADIUS statistics.

The following example shows how to display statistics:

switch# show radius-server statistics 10.10.1.1

Example RADIUS Configuration

The following example shows how to configure RADIUS:

radius-server key 7 "ToIkLhPpG"

radius-server host 10.10.1.1 key 7 "ShMoMhTl" authentication accounting

aaa group server radius RadServer

server 10.10.1.1

use-vrf management

Default Settings

Table 1-1 Default RADIUS Parameters

Parameters

Default

Server roles

Authentication and accounting

Dead timer interval

0 minutes

Retransmission count

1

Retransmission timer interval

5 seconds

Idle timer interval

0 minutes

Periodic server monitoring username

test

Periodic server monitoring password

Configuring User Accounts and RBAC

This chapter describes how to configure user accounts and role-based access control (RBAC) on the Nexus 5000 Series switch.

This chapter includes the following sections:

- Information About User Accounts and RBAC

- Guidelines and Limitations

- Configuring User Accounts

- Configuring RBAC

- Verifying User Accounts and RBAC Configuration

- Example User Accounts and RBAC Configuration

- Default Settings

Information About User Accounts and RBAC

You can create and manage users accounts and assign roles that limit access to operations on the Nexus 5000 Series switch. RBAC allows you to define the rules for an assign role that restrict the authorization that the user has to access management operations.

This section includes the following topics:

- About User Accounts

- Characteristics of Strong Passwords

- About User Roles

- About Rules

- About User Role Policies

About User Accounts

Tip The following words are reserved and cannot be used to configure users: bin, daemon, adm, lp, sync, shutdown, halt, mail, news, uucp, operator, games, gopher, ftp, nobody, nscd, mailnull, rpc, rpcuser, xfs, gdm, mtsuser, ftpuser, man, and sys.

Note User passwords are not displayed in the configuration files.

Caution The Nexus 5000 Series switch does not support all numeric usernames, whether created with TACACS+ or RADIUS, or created locally. Local users with all numeric names cannot be created. If an all numeric user name exists on an AAA server and is entered during login, the user is not logged in. Usernames must begin with an alphanumeric character and can contain only these special characters: ( + = . _ \ -). The # and ! symbols are not supported. If the username contains characters that are not allowed, the specified user is unable to log in.

Characteristics of Strong Passwords

A strong password has the following characteristics:

- At least eight characters long

- Does not contain many consecutive characters (such as “abcd”)

- Does not contain many repeating characters (such as “aaabbb”)

- Does not contain dictionary words

- Does not contain proper names

- Contains both uppercase and lowercase characters

- Contains numbers

The following are examples of strong passwords:

- If2CoM18

- 2004AsdfLkj30

- Cb1955S21

Note Clear text passwords can contain alphanumeric characters only. Special characters, such as the dollar sign ($) or the percent sign (%), are not allowed.

Tip If a password is trivial (such as a short, easy-to-decipher password), the Nexus 5000 Series switch will reject your password configuration. Be sure to configure a strong password as shown in the sample configuration. Passwords are case sensitive.

About User Roles

User roles contain rules that define the operations allowed for the user who is assigned the role. Each user role can contain multiple rules and each user can have multiple roles. For example, if role1 allows access only to configuration operations, and role2 allows access only to debug operations, then users who belong to both role1 and role2 can access configuration and debug operations. You can also limit access to specific VSANs, VLANs and interfaces.

The Nexus 5000 Series switch provides the following default user roles:

- network-admin (superuser)—Complete read and write access to the entire Nexus 5000 Series switch.

- network-operator—Complete read access to the Nexus 5000 Series switch.

Note If you belong to multiple roles, you can execute a combination of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose a user has RoleA, which denied access to the configuration commands. However, the users also has RoleB, which has access to the configuration commands. In this case, the users has access to the configuration commands.

About Rules

The rule is the basic element of a role. A rule defines what operations the role allows the user to perform. You can apply rules for the following parameters:

- Command—A command or group of commands defined in a regular expression.

- Feature—Commands that apply to a function provided by the Nexus 5000 Series switch.

– Enter the show role feature command to display the feature names available for this parameter.

- Feature group—Default or user-defined group of features.

– Enter the show role feature-group command to display the default feature groups available for this parameter.

These parameters create a hierarchical relationship. The most basic control parameter is the command. The next control parameter is the feature, which represents all commands associated with the feature. The last control parameter is the feature group. The feature group combines related features and allows you to easily manage of the rules.

You can configure up to 256 rules for each role. The user-specified rule number determines the order in which the rules are applied. Rules are applied in descending order. For example, if a role has three rules, rule 3 is applied before rule 2, which is applied before rule 1.

About User Role Policies

You can define user role policies to limit the switch resources that the user can access. You can define user role policies to limit access to interfaces, VLANs and VSANs.

User role policies are constrained by the rules defined for the role. For example, if you define an interface policy to permit access to specific interfaces, the user will not have access to the interfaces unless you configure a command rule for the role to permit the interface command. The Changing User Role Interface Policies contains an example configuration.

If a command rule permits access to specific resources (interfaces, VLANs or VSANs), the user is permitted to access these resources, even if they are not listed in the user role policies associated with that user.

Guidelines and Limitations

User account and RBAC have the following configuration guidelines and limitations:

- You can add up to 256 rules to a user role.

- You can assign a maximum of 64 user roles to a user account.

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

Note A user account must have at least one user role.

Configuring User Accounts

You can create a maximum of 256 user accounts on a Nexus 5000 Series switch. User accounts have the following attributes:

- Username

- Password

- Expiry date

- User roles

User accounts can have a maximum of 64 user roles. For more information on user roles, see the “Configuring RBAC” section.

Note Changes to user account attributes do not take effect until the user logs in and creates a new session.

Command

Purpose

Step 1

switch(config)# show role

(Optional) Displays the user roles available. You can configure other user roles, if necessary (see the “Creating User Roles and Rules” section)

Step 2

switch# configure terminal

switch(config)#

Enters global configuration mode.

Step 3

switch(config)# username user-id [password password] [expire date] [role role-name]

Configure a user account. The user-id argument is a case-sensitive, alphanumeric character string with a maximum length of 28 characters.

The default password is undefined.

Note If you do not specify a password, the user might not be able to log in to the Nexus 5000 Series switch.
The expire date option format is YYYY-MM-DD. The default is no expiry date.

Step 4

switch(config)# exit

switch#

Exits global configuration mode.

Step 5

switch# show user-account

(Optional) Displays the role configuration.

Step 6

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure a user account:

switch# configure terminal

switch(config)# username NewUser password 4Ty18Rnt

switch(config)# exit

switch# show user-account

switch# copy running-config startup-config

Configuring RBAC

This section includes the following topics:

- Creating User Roles and Rules

- Changing User Role Interface Policies

Creating User Roles and Rules

Each user role can have up to 256 rules. You can assign a user role to more that one user account.

The rule number you specify determines the order in which the rules are applied. Rules are applied in descending order. For example, if a role has three rules, rule 3 is applied before rule 2, which is applied before rule 1.

To create user roles and specify rules, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# role name role-name

Specifies a user role and enters role configuration mode. The role-name argument is a case-sensitive, alphanumeric character string with a maximum length of 16 characters.

Step 3

switch(config-role)# rule number {deny | permit} command command-string

Configures a command rule.

The command-string argument can contain spaces and regular expressions. For example, “interface ethernet *” includes all Ethernet interfaces.

Repeat this command for as many rules as needed.

switch(config-role)# rule number {deny | permit} {read | read-write}

Configures a read only or read and write rule for all operations.

switch(config-role)# rule number {deny | permit} {read | read-write} feature feature-name

Configures a read-only or read-and-write rule for a feature.

Use the show role feature command to display a list of features.

Repeat this command for as many rules as needed.

switch(config-role)#

rule number {deny | permit} {read | read-write} feature-group group-name

Configures a read-only or read-and-write rule for a feature group.

Use the show role feature-group command to display a list of feature groups.

Repeat this command for as many rules as needed.

Step 4

switch(config-role)# description text

(Optional) Configures the role description. You can include spaces in the description.

Step 5

switch(config-role)# exit

Exits role configuration mode.

Step 6

switch(config)# show role

(Optional) Displays the user role configuration.

Step 7

switch(config)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to create user roles and specify rules:

switch# configure terminal

switch(config)# role name UserA

switch(config-role)# rule deny command clear users

switch(config-role)# rule deny read-write

switch(config-role)# rule permit read feature router-bgp

switch(config-role)# rule deny read-write L3

switch(config-role)# description This role does not allow users to use clear commands

switch(config-role)# exit

switch(config)# show role

switch(config)# copy running-config startup-config

Creating Feature Groups

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# role feature-group group-name

Specifies a user role feature group and enters role feature group configuration mode.

The group-name argument is a case-sensitive, alphanumeric character string with a maximum length of 32 characters.

Step 3

switch(config-role-featuregrp)# exit

Exits role feature group configuration mode.

Step 4

switch(config)# show role feature-group

(Optional) Displays the role feature group configuration.

Step 5

switch(config)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Changing User Role Interface Policies

You can change a user role interface policy to limit the interfaces that the user can access. To change a user role interface policy, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# role name role-name

Specifies a user role and enters role configuration mode.

Step 3

switch(config-role)# rule number permit command configure terminal ; interface *

Configures a command rule to allow access to all interfaces.

Step 4

switch(config-role)# interface policy deny

Enters role interface policy configuration mode.

Step 5

switch(config-role-interface)# permit interface interface-list

Specifies a list of interfaces that the role can access.

Repeat this command for as many interfaces as needed.

For this command, you can specify Ethernet interfaces, Fibre Channel interfaces and virtual Fibre Channel interfaces.

Step 6

switch(config-role-interface)# exit

Exits role interface policy configuration mode.

Step 7

switch(config-role)# show role

(Optional) Displays the role configuration.

Step 8

switch(config-role)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

You can specify a list of interfaces that the role can access. You can specify it for as many interfaces as needed:

switch(config-role-interface)# permit interface ethernet 2/1

switch(config-role-interface)# permit interface fc 3/1

switch(config-role-interface)# permit interface vfc 30/1

Changing User Role VLAN Policies

You can change a user role VLAN policy to limit the VLANs that the user can access. To change a user role VLAN policy, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# role name role-name

Specifies a user role and enters role configuration mode.

Step 3

switch(config-role)# rule number permit command configure terminal ; vlan *

Configures a command rule to allow access to all VLANs.

Step 4

switch(config-role)# vlan policy deny

Enters role VLAN policy configuration mode.

Step 5

switch(config-role-vlan)# permit vlan vlan-list

Specifies a range of VLANs that the role can access.

Repeat this command for as many VLANs as needed.

Step 6

switch(config-role-vlan)# exit

Exits role VLAN policy configuration mode.

Step 7

switch(config-role)# show role

(Optional) Displays the role configuration.

Step 8

switch(config-role)# copy running-config startup-config

Changing User Role VSAN Policies

You can change a user role VSAN policy to limit the VSANs that the user can access.

To change a user role VSAN policy to limit the VSANs that the user can access, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config-role)# role name role-name

Specifies a user role and enters role configuration mode.

Step 3

switch(config-role)# rule number permit command vsan database; vsan *

Configures a command rule to allow access to all VSANs.

Step 4

switch(config-role)# vsan policy deny

Enters role VSAN policy configuration mode.

Step 5

switch(config-role-vsan)# permit vsan vsan-list

Specifies a range of VSANs that the role can access.

Repeat this command for as many VSANs as needed.

Step 6

switch(config-role-vsan)# exit

Exits role VSAN policy configuration mode.

Step 7

switch(config-role)# show role

Example:

switch(config-role)# show role

(Optional) Displays the role configuration.

Step 8

switch(config-role)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Verifying User Accounts and RBAC Configuration

To display user account and RBAC configuration information, perform one of the following tasks:

Command

Purpose

show role

Displays the user role configuration

show role feature

Displays the feature list.

show role feature-group

Displays the feature group configuration.

show startup-config security

Displays the user account configuration in the startup configuration.

show running-config security [all]

Displays the user account configuration in the running configuration. The all keyword displays the default values for the user accounts.

show user-account

Displays user account information.

Example User Accounts and RBAC Configuration

role feature-group name Security-features

feature radius

feature tacacs

feature aaa

feature acl

feature access-list

Default Settings

Table 1-1 Default User Accounts and RBAC Parameters

Parameters

Default

User account password

Undefined.

User account expiry date.

None.

Interface policy

All interfaces are accessible.

VLAN policy

All VLANs are accessible.

VFC policy

All VFCs are accessible.

VETH policy

Configuring TACACS+

This chapter describes how to configure the Terminal Access Controller Access Control System Plus (TACACS+) protocol on Nexus 5000 Series switches.

This chapter includes the following sections:

- Information About TACACS+

- Prerequisites for TACACS+

- Guidelines and Limitations

- Configuring TACACS+

- Displaying TACACS+ Statistics

- Verifying TACACS+ Configuration

- Example TACACS+ Configuration

- Default Settings

Information About TACACS+

The TACACS+ security protocol provides centralized validation of users attempting to gain access to a Nexus 5000 Series switch. TACACS+ services are maintained in a database on a TACACS+ daemon typically running on a UNIX or Windows NT workstation. You must have access to and must configure a TACACS+ server before the configured TACACS+ features on your Nexus 5000 Series switch are available.

TACACS+ provides for separate authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service (authentication, authorization, and accounting) independently. Each service is associated with its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.

The TACACS+ client/server protocol uses TCP (TCP port 49) for transport requirements. Nexus 5000 Series switches provide centralized authentication using the TACACS+ protocol.

This section includes the following topics:

- TACACS+ Advantages

- User Login with TACACS+

- Default TACACS+ Server Encryption Type and Preshared Key

- TACACS+ Server Monitoring

TACACS+ Advantages

TACACS+ has the following advantages over RADIUS authentication:

- Provides independent AAA facilities. For example, the Nexus 5000 Series switch can authorize access without authenticating.

- Uses the TCP transport protocol to send data between the AAA client and server, making reliable transfers with a connection-oriented protocol.

- Encrypts the entire protocol payload between the switch and the AAA server to ensure higher data confidentiality. The RADIUS protocol only encrypts passwords.

User Login with TACACS+

When a user attempts a Password Authentication Protocol (PAP) login to a Nexus 5000 Series switch using TACACS+, the following actions occur:

1. When the Nexus 5000 Series switch establishes a connection, it contacts the TACACS+ daemon to obtain the username and password.

Note TACACS+ allows an arbitrary conversation between the daemon and the user until the daemon receives enough information to authenticate the user. This action is usually done by prompting for a username and password combination, but may include prompts for other items, such as the user’s mother’s maiden name.

2. The Nexus 5000 Series switch will receive one of the following responses from the TACACS+ daemon:

- ACCEPT—User authentication succeeds and service begins. If the Nexus 5000 Series switch requires user authorization, authorization begins.

- REJECT—User authentication failed. The TACACS+ daemon either denies further access to the user or prompts the user to retry the login sequence.

- ERROR—An error occurred at some time during authentication dither at the daemon or in the network connection between the daemon and the Nexus 5000 Series switch. If the Nexus 5000 Series switch receives an ERROR response, the Nexus 5000 Series switch tries to use an alternative method for authenticating the user.

The user also undergoes an additional authorization phase, if authorization has been enabled on the Nexus 5000 Series switch. Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.

3. If TACACS+ authorization is required, the Nexus 5000 Series switch again contacts the TACACS+ daemon and it returns an ACCEPT or REJECT authorization response. An ACCEPT response contains attributes that are used to direct the EXEC or NETWORK session for that user and determines the services that the user can access.

Services include the following:

- Telnet, rlogin, Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), or EXEC services

- Connection parameters, including the host or client IP address (IPv4 or IPv6), access list, and user timeouts

Default TACACS+ Server Encryption Type and Preshared Key

You must configure the TACACS+ preshared key to authenticate the switch to the TACACS+ server. A preshared key is a secret text string shared between the Nexus 5000 Series switch and the TACACS+ server host. The length of the key is restricted to 63 characters and can include any printable ASCII characters (white spaces are not allowed). You can configure a global preshared secret key for all TACACS+ server configurations on the Nexus 5000 Series switch to use.

You can override the global preshared key assignment by explicitly using the key option when configuring an individual TACACS+ server.

TACACS+ Server Monitoring

An unresponsive TACACS+ server can delay the processing of AAA requests. A Nexus 5000 Series switch can periodically monitor an TACACS+ server to check whether it is responding (or alive) to save time in processing AAA requests. The Nexus 5000 Series switch marks unresponsive TACACS+ servers as dead and does not send AAA requests to any dead TACACS+ servers. A Nexus 5000 Series switch periodically monitors dead TACACS+ servers and brings them to the alive state once they are responding. This process verifies that a TACACS+ server is in a working state before real AAA requests are sent its way. Whenever an TACACS+ server changes to the dead or alive state, a Simple Network Management Protocol (SNMP) trap is generated and the Nexus 5000 Series switch displays an error message that a failure is taking place before it can impact performance. See Figure 1-1.

Figure 1-1 TACACS+ Server States

Note The monitoring interval for alive servers and dead servers are different and can be configured by the user. The TACACS+ server monitoring is performed by sending a test authentication request to the TACACS+ server.

Prerequisites for TACACS+

TACACS+ has the following prerequisites:

- Obtain the IPv4 or IPv6 addresses or host names for the TACACS+ servers.

- Obtain the preshared keys from the TACACS+ servers, if any.

- Ensure that the Nexus 5000 Series switch is configured as a TACACS+ client of the AAA servers.

Guidelines and Limitations

TACACS+ has the following guidelines and limitations:

- You can configure a maximum of 64 TACACS+ servers on the Nexus 5000 Series switch.

Configuring TACACS+

This section includes the following topics:

- TACACS+ Server Configuration Process

- Enabling TACACS+

- Configuring TACACS+ Server Hosts

- Configuring Global Preshared Keys

- Configuring TACACS+ Server Preshared Keys

- Configuring TACACS+ Server Groups

- Specifying a TACACS+ Server at Login

- Configuring the Global TACACS+ Timeout Interval

- Configuring the Timeout Interval for a Server

- Configuring TCP Ports

- Configuring Periodic TACACS+ Server Monitoring

- Configuring the Dead-Time Interval

- Manually Monitoring TACACS+ Servers or Groups

- Disabling TACACS+

Note If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.

TACACS+ Server Configuration Process

To configure TACACS+ servers, perform this task:

Step 1 Enable TACACS+.

See the “Enabling TACACS+” section.

Step 2 Establish the TACACS+ server connections to the Nexus 5000 Series switch.

See the “Configuring TACACS+ Server Hosts” section.

Step 3 Configure the preshared secret keys for the TACACS+ servers.

See the “Configuring Global Preshared Keys” section and the “Configuring TACACS+ Server Preshared Keys” section.

Step 4 If needed, configure TACACS+ server groups with subsets of the TACACS+ servers for AAA authentication methods.

See the “Configuring TACACS+ Server Groups” section and the “Configuring AAA” section.

Step 5 If needed, configure any of the following optional parameters:

- Dead-time interval

- Allow TACACS+ server specification at login

- Timeout interval

See the “Configuring the Global TACACS+ Timeout Interval” section.

- TCP port

See the “Configuring TCP Ports” section.

Step 6 If needed, configure periodic TACACS+ server monitoring.

Enabling TACACS+

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# feature tacacs+

Enables TACACS+.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring TACACS+ Server Hosts

To access a remote TACACS+ server, you must configure the IPv4 or IPv6 address or the hostname for the TACACS+ server on the Nexus 5000 Series switch. All TACACS+ server hosts are added to the default TACACS+ server group.You can configure up to 64 TACACS+ servers.

If a preshared key is not configured for a configured TACACS+ server, a warning message is issued if a global key is not configured. If a TACACS+ server key is not configured, the global key (if configured) is used for that server (see the “Configuring Global Preshared Keys” section and the “Configuring TACACS+ Server Preshared Keys” section).

Before you configure TACACS+ server hosts, you should do the following:

- Enable TACACS+ (see the “Enabling TACACS+” section).

- Obtain the IPv4 or IPv6addresses or the hostnames for the remote TACACS+ servers.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server host {ipv4-address | ipv6-address|host-name}

Specifies the IPv4 or IPv6 address or hostname for a TACACS+ server.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

You can delete a TACACS+ server host from a server group.

Configuring Global Preshared Keys

You can configure preshared keys at the global level for all servers used by the Nexus 5000 Series switch. A preshared key is a shared secret text string between the Nexus 5000 Series switch and the TACACS+ server hosts.

Before you configure preshared keys, you should do the following:

- Enable TACACS+ (see the “Enabling TACACS+” section).

- Obtain the preshared key values for the remote TACACS+ servers.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server key [0|7] key-value

Specifies a preshared key for all TACACS+ servers. You can specify a clear text (0) or encrypted (7) preshared key. The default format is clear text. The maximum length is 63 characters.

By default, no preshared key is configured.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.
command to display the encrypted preshared keys.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure global preshared keys:

switch# configure terminal

switch(config)# tacacs-server key 0 QsEfThUkO

switch(config)# exit

switch# show tacacs-server

switch# copy running-config startup-config

Configuring TACACS+ Server Preshared Keys

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server host {ipv4-address|ipv6-address|host-name} key [0|7] key-value

Specifies a preshared key for a specific TACACS+ server. You can specify a clear text (0) or encrypted (7) preshared key. The default format is clear text. The maximum length is 63 characters.

This preshared key is used instead of the global preshared key.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.
command to display the encrypted preshared keys.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure the TACACS+ preshared keys:

switch# configure terminal

switch(config)# tacacs-server host 10.10.1.1 key 0 PlIjUhYg

switch(config)# exit

switch# show tacacs-server

switch# copy running-config startup-config

Configuring TACACS+ Server Groups

You can specify one or more remote AAA servers to authenticate users using server groups. All members of a group must belong to the TACACS+ protocol. The servers are tried in the same order in which you configure them.

You can configure these server groups at any time but they only take effect when you apply them to an AAA service. For information on AAA services, see the “Remote AAA Services” section.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# aaa group server tacacs+ group-name

Creates a TACACS+ server group and enters the TACACS+ server group configuration mode for that group.

Step 3

switch(config-tacacs+)# server {ipv4-address|ipv6-address|host-name}

Configures the TACACS+ server as a member of the TACACS+ server group.
command and retry this command.

Step 4

switch(config-tacacs+)# deadtime minutes

(Optional) Configures the monitoring dead time. The default is 0 minutes. The range is from 0 through 1440.

Note If the dead-time interval for a TACACS+ server group is greater than zero (0), that value takes precedence over the global dead-time value.

Step 5

switch(config-tacacs+)# exit

Exits configuration mode.

Step 6

switch(config)# show tacacs-server groups

(Optional) Displays the TACACS+ server group configuration.

Step 7

switch(config)# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure a TACACS+ server group:

switch# configure terminal

switch(config)# aaa group server tacacs+ TacServer

switch(config-tacacs+)# server 10.10.2.2

switch(config-tacacs+)# deadtime 30

switch(config-tacacs+)# exit

switch(config)# show tacacs-server groups

switch(config)# copy running-config startup-config

Specifying a TACACS+ Server at Login

You can configure the switch to allow the user to specify which TACACS+ server to send the authenticate request by enabling the directed-request option. By default, a Nexus 5000 Series switch forwards an authentication request based on the default AAA authentication method. If you enable this option, the user can log in as username@hostname, where hostname is the name of a configured RADIUS server.

Note User specified logins are only supported for Telnet sessions.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server directed-request

Allows users to specify a TACACS+ server to send the authentication request when logging in. The default is disabled.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server directed-request

(Optional) Displays the TACACS+ directed request configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring the Global TACACS+ Timeout Interval

You can set a global timeout interval that the Nexus 5000 Series switch waits for responses from all TACACS+ servers before declaring a timeout failure. The timeout interval determines how long the Nexus 5000 Series switch waits for responses from TACACS+ servers before declaring a timeout failure.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server timeout seconds

Specifies the timeout interval for TACACS+ servers. The default timeout interval is 5 second and the range is from 1 to 60 seconds.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring the Timeout Interval for a Server

You can set a timeout interval that the Nexus 5000 Series switch waits for responses from a TACACS+ server before declaring a timeout failure. The timeout interval determines how long the Nexus 5000 Series switch waits for responses from a TACACS+ server before declaring a timeout failure.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# switch(config)# tacacs-server host {ipv4-address|ipv6-address|host-name} timeout seconds

Specifies the timeout interval for a specific server. The default is the global value.

Note The timeout interval value specified for a TACACS+ server overrides the global timeout interval value specified for all TACACS+ servers.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Configuring TCP Ports

You can configure another TCP port for the TACACS+ servers if there are conflicts with another application. By default, Nexus 5000 Series switches use port 49 for all TACACS+ requests.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server host {ipv4-address|ipv6-address|host-name} port tcp-port

Specifies the TCP port to use for TACACS+ accounting messages.The default TCP port is 49. The range is from 1 to 65535.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure TCP ports:

switch# configure terminal

switch(config)# tacacs-server host 10.10.1.1 port 2

switch(config)# exit

switch# show tacacs-server

switch# copy running-config startup-config

Configuring Periodic TACACS+ Server Monitoring

You can monitor the availability of TACACS+ servers. These parameters include the username and password to use for the server and an idle timer. The idle timer specifies the interval in which a TACACS+ server receives no requests before the Nexus 5000 Series switch sends out a test packet.You can configure this option to test servers periodically, or you can run a one-time only test.

Note To protect network security, we recommend that you use a user name that is not the same as an existing username in the TACACS+ database.

The test idle timer specifies the interval in which a TACACS+ server receives no requests before the Nexus 5000 Series switch sends out a test packet.

Note The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, periodic TACACS+ server monitoring is not performed.

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server host {ipv4-address | ipv6-address | host-name} test {idle-time minutes | password password [idle-time minutes] | username name [password password [idle-time minutes]]}

Specifies parameters for server monitoring. The default username is test and the default password is test. The default value for the idle timer is 0 minutes and the valid range is 0 to 1440 minutes.

Note For periodic TACACS+ server monitoring, the idle timer value must be greater than 0.

Step 3

switch(config)# tacacs-server dead-time minutes

Specifies the number minutes before the Nexus 5000 Series switch checks a TACACS+ server that was previously unresponsive. The default value is 0 minutes and the valid range is 0 to 1440 minutes.

Step 4

switch(config)# exit

Exits configuration mode.

Step 5

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 6

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

The following example shows how to configure periodic TACACS+ server monitoring:

switch# configure terminal

switch(config)# tacacs-server host 10.10.1.1 test username user1 password Ur2Gd2BH idle-time 3

switch(config)# tacacs-server dead-time 5

switch(config)# exit

switch# show tacacs-server

switch# copy running-config startup-config

Configuring the Dead-Time Interval

You can configure the dead-time interval for all TACACS+ servers. The dead-time interval specifies the time that the Nexus 5000 Series switch waits, after declaring a TACACS+ server is dead, before sending out a test packet to determine if the server is now alive.

Note When the dead-timer interval is 0 minutes, TACACS+ servers are not marked as dead even if they are not responding. You can configure the dead-timer per group (see the “Configuring TACACS+ Server Groups” section).

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# tacacs-server deadtime minutes

Configures the global dead-time interval. The default value is 0 minutes. The range is from 1 to 1440 minutes.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# show tacacs-server

(Optional) Displays the TACACS+ server configuration.

Step 5

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Manually Monitoring TACACS+ Servers or Groups

To manually issue a test message to a TACACS+ server or to a server group, perform this task:

Command

Purpose

Step 1

switch# test aaa server tacacs+ {ipv4-address|ipv6-address|host-name} [vrf vrf-name] username password

Sends a test message to a TACACS+ server to confirm availability.

Step 1

switch# test aaa group group-name username password

Sends a test message to a TACACS+ server group to confirm availability.

The following example shows how to manually issue a test message:

switch# test aaa server tacacs+ 10.10.1.1 user1 Ur2Gd2BH

switch# test aaa group TacGroup user2 As3He3CI

Disabling TACACS+

You can disable TACACS+.

Caution When you disable TACACS+, all related configurations are automatically discarded.

To disable TACACS+, perform this task:

Command

Purpose

Step 1

switch# configure terminal

Enters configuration mode.

Step 2

switch(config)# feature tacacs+

Enables TACACS+.

Step 3

switch(config)# exit

Exits configuration mode.

Step 4

switch# copy running-config startup-config

(Optional) Copies the running configuration to the startup configuration.

Displaying TACACS+ Statistics

To display the statistics the Nexus 5000 Series switch maintains for TACACS+ activity, perform this task:

Command

Purpose

Step 1

switch# show tacacs-server statistics {hostname|ipv4-address|ipv6-address}

Displays the TACACS+ statistics.

For detailed information about the fields in the output from this command, see the Cisco Nexus 5000 Series Command Reference.

Verifying TACACS+ Configuration

Command

Purpose

show running-config tacacs [all]

Displays the TACACS+ configuration in the running configuration.

show startup-config tacacs

Displays the TACACS+ configuration in the startup configuration.

show tacacs-server [host-name | ipv4-address | ipv6-address] [directed-request | groups | sorted | statistics]

Displays all configured TACACS+ server parameters.

Example TACACS+ Configuration

The following example shows how to configure TACACS+:

feature tacacs+

tacacs-server key 7 "ToIkLhPpG"

tacacs-server host 10.10.2.2 key 7 "ShMoMhTl"

aaa group server tacacs+ TacServer

server 10.10.2.2

use-vrf management

Default Settings

Table 1-1 lists the default settings for TACACS+ parameters.

Table 1-1 Default TACACS+ Parameters

Parameters

Default

TACACS+

Disabled

Dead timer interval

0 minutes

Timeout interval

5 seconds

Idle timer interval

0 minutes

Periodic server monitoring username

test

Periodic server monitoring password

Configuring VSAN Trunking

This chapter describes the VSAN trunking feature provided in Cisco Nexus 5000 Series switches.

This chapter includes the following sections:

- Information About VSAN Trunking

- Configuring VSAN Trunking

- Displaying VSAN Trunking Information

- Default Settings

Information About VSAN Trunking

VSAN trunking enables interconnect ports to transmit and receive frames in more than one VSAN, over the same physical link, using enhanced ISL (EISL) frame format (see Figure 1-1).

VSAN trunking is supported on native Fibre Channel interfaces, but not on virtual Fibre Channel interfaces.

Figure 1-1 VSAN Trunking

The VSAN trunking feature includes the following restrictions:

- Trunking configurations are only applicable to E ports. If trunk mode is enabled in an E port and that port becomes operational as a trunking E port, it is referred to as a TE port.

- The trunk-allowed VSANs configured for TE ports are used by the trunking protocol to determine the allowed-active VSANs in which frames can be received or transmitted.

- If a trunking-enabled E port is connected to a third-party switch, the trunking protocol ensures seamless operation as an E port.

Additional information about VSAN trunking is covered in the following topics:

- VSAN Trunking Mismatches

- VSAN Trunking Protocol

VSAN Trunking Mismatches

If you misconfigure VSAN configurations across E ports, issues can occur such as the merging of traffic in two VSANs (causing both VSANs to mismatch). The VSAN trunking protocol validates the VSAN interfaces at both ends of an ISL to avoid merging VSANs (see Figure 1-2).

Figure 1-2 VSAN Mismatch

In this example, the trunking protocol detects potential VSAN merging and isolates the ports involved.

The trunking protocol cannot detect merging of VSANs when a third-party switch is placed in between two Cisco Nexus 5000 Series switches (see Figure 1-3).

Figure 1-3 Third-Party Switch VSAN Mismatch

VSAN 2 and VSAN 3 are effectively merged with overlapping entries in the name server and the zone applications. The Cisco MDS 9000 Fabric Manager helps detect such topologies.

VSAN Trunking Protocol

The trunking protocol is important for E-port and TE-port operations. It supports the following capabilities:

- Dynamic negotiation of operational trunk mode.

- Selection of a common set of trunk-allowed VSANs.

- Detection of a VSAN mismatch across an ISL.

By default, the VSAN trunking protocol is enabled. If the trunking protocol is disabled on a switch, no port on that switch can apply new trunk configurations. Existing trunk configurations are not affected: the TE port continues to function in trunk mode, but only supports traffic in VSANs that it negotiated with previously (when the trunking protocol was enabled). Other switches that are directly connected to this switch are similarly affected on the connected interfaces. If you need to merge traffic from different port VSANs across a nontrunking ISL, disable the trunking protocol.

Configuring VSAN Trunking

This section explains how to configure VSAN trunking and includes the following topics:

- Guidelines and Restrictions

- Enabling or Disabling the VSAN Trunking Protocol

- About Trunk Mode

- Configuring Trunk Mode

- About Trunk-Allowed VSAN Lists

- Configuring an Allowed-Active List of VSANs

Guidelines and Restrictions

When configuring VSAN trunking, note the following guidelines:

- We recommend that both ends of a VSAN trunking ISL belong to the same port VSAN. On platforms or fabric switches where the port VSANs are different, one end returns an error, and the other is not connected.

- To avoid inconsistent configurations, disable all E ports with a shutdown command before enabling or disabling the VSAN trunking protocol.

Enabling or Disabling the VSAN Trunking Protocol

To enable or disable the VSAN trunking protocol, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# no trunk protocol enable

switch(config)#

Disables the trunking protocol.

switch(config)# trunk protocol enable

switch(config)#

Enables trunking protocol (default).

About Trunk Mode

By default, trunk mode is enabled in all Fibre Channel interfaces. However, trunk mode configuration takes effect only in E-port mode. You can configure trunk mode as on (enabled), off (disabled), or auto (automatic). The default trunk mode is on. The trunk mode configurations at the two ends of the link determine the trunking state of the link and the port modes at both ends (see Table 1-1).

Table 1-1 Trunk Mode Status Between Switches

Your Trunk Mode Configuration

Resulting State and Port Mode

Switch 1

Switch 2

Trunking State

Port Mode

On

Auto or on

Trunking (EISL)

TE port

Off

Auto, on, or off

No trunking (ISL)

E port

Auto

Auto

No trunking (ISL)

E port

Tip The preferred configuration on the Cisco Nexus 5000 Series switches is that one side of the trunk is set to auto and the other is set to on.

Note When connected to a third-party switch, the trunk mode configuration has no effect. The ISL is always in a trunking disabled state.

Configuring Trunk Mode

To configure trunk mode, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

switch(config-if)#

Configures the specified interface.

Step 3

switch(config-if)# switchport trunk mode on

Enables (default) the trunk mode for the specified interface.

switch(config-if)# switchport trunk mode off

Disables the trunk mode for the specified interface.

switch(config-if)# switchport trunk mode auto

Configures the trunk mode to auto mode, which provides automatic sensing for the interface.

About Trunk-Allowed VSAN Lists

Each Fibre Channel interface has an associated trunk-allowed VSAN list. In TE-port mode, frames are transmitted and received in one or more VSANs specified in this list. By default, the complete VSAN range (1 through 4093) is included in the trunk-allowed list.

The common set of VSANs that are configured and active in the switch are included in the trunk-allowed VSAN list for an interface, and they are called allowed-active VSANs. The trunking protocol uses the list of allowed-active VSANs at the two ends of an ISL to determine the list of operational VSANs in which traffic is allowed.

In Figure 1-4, switch 1 has VSANs 1 through 5, switch 2 has VSANs 1 through 3, and switch 3 has VSANs 1, 2, 4, and 5 with a default configuration of trunk-allowed VSANs. All VSANs configured in all three switches are allowed-active. However, only the common set of allowed-active VSANs at the ends of the ISL become operational as shown in Figure 1-4.

Figure 1-4 Default Allowed-Active VSAN Configuration

You can configure a selected set of VSANs (from the allowed-active list) to control access to the VSANs specified in a trunking ISL.

Using Figure 1-4 as an example, you can configure the list of allowed VSANs on a per-interface basis (see Figure 1-5). For example, if VSANs 2 and 4 are removed from the allowed VSAN list of ISLs connecting to switch 1, the operational allowed list of VSANs for each ISL would be as follows:

- The ISL between switch 1 and switch 2 includes VSAN 1 and VSAN 3.

- The ISL between switch 2 and switch 3 includes VSAN 1 and VSAN 2.

- The ISL between switch 3 and switch 1 includes VSAN 1, 2, and 5.

Consequently, VSAN 2 can only be routed from switch 1 through switch 3 to switch 2.

Figure 1-5 Operational and Allowed VSAN Configuration

Configuring an Allowed-Active List of VSANs

To configure an allowed-active list of VSANs for an interface, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# interface fc slot/port

switch(config-if)#

Configures the specified interface.

Step 3

switch(config-if)# switchport trunk allowed vsan vsan-id - vsan-id

Changes the allowed list for the specified VSAN range.

switch(config-if)# switchport trunk allowed vsan add vsan-id

updated trunking membership

Expands the specified VSAN to the new allowed list.

switch(config-if)# no switchport trunk allowed vsan vsan-id - vsan-id

Deletes the specified VSAN range.

switch(config-if)# no switchport trunk allowed vsan add vsan-id

Deletes the expanded allowed list.

Displaying VSAN Trunking Information

The show interface command is invoked from the EXEC mode and displays VSAN trunking configurations for a TE port. Without any arguments, this command displays the information for all of the configured interfaces in the switch.

The following example shows how to display the trunk mode of a Fibre Channel interface:

switch# show interface fc3/3

fc3/3 is up

Hardware is Fibre Channel, SFP is short wave laser w/o OFC (SN)

Port WWN is 20:83:00:0d:ec:6d:78:40

Peer port WWN is 20:0c:00:0d:ec:0d:d0:00

Admin port mode is auto, trunk mode is on

...

The following example shows how to display the trunk protocol of a Fibre Channel interface:

switch# show trunk protocol

Trunk protocol is enabled

The following example shows how to display the VSAN information for all trunk interfaces:

switch# show interface trunk vsan 1-1000

fc3/1 is not trunking

...

fc3/11 is trunking

Belongs to san-port-channel 6

Vsan 1 is up, FCID is 0xef0000

Vsan 2 is up, FCID is 0xef0000

...

san-port-channel 6 is trunking

Vsan 1 is up, FCID is 0xef0000

Vsan 2 is up, FCID is 0xef0000

Default Settings

Table 1-2 lists the default settings for trunking parameters.

Table 1-2 Default Trunk Configuration Parameters

Parameters

Default

Switch port trunk mode

On

Allowed VSAN list

1 to 4093 user-defined VSAN IDs

Trunking protocol

Enabled

Troubleshooting

This chapter describes basic troubleshooting methods used to resolve issues with a Cisco Nexus 5000 Series switch. This chapter includes the following sections:

- Recovering a Lost Password

- Using Ethanalyzer

- Troubleshooting Fibre Channel

- show tech-support Command

- Default Settings

Recovering a Lost Password

This section describes how to recover a lost network administrator password using the console port of the switch.

You can recover the network administrator password using one of two methods:

- From the CLI with a username that has network-admin privileges

- By power cycling the switch

This section includes the following topics:

- Using the CLI with Network-Admin Privileges

- Power Cycling the Switch

Using the CLI with Network-Admin Privileges

If you are logged in to, or can log into, the switch with a username that has network-admin privileges, follow these steps:

Step 1 Verify that your username has network-admin privileges.

switch# show user-account

user:admin

this user account has no expiry date

roles:network-admin

user:dbgusr

this user account has no expiry date

roles:network-admin network-operator

Step 2 Assign a new network administrator password if your username has network-admin privileges.

switch# configure terminal

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 3 Save the configuration.

switch# copy running-config startup-config

Power Cycling the Switch

If you cannot start a session on the switch that has network-admin privileges, you must recover the network administrator password by power cycling the switch.

Caution This procedure disrupts all traffic on the switch.

Note You cannot recover the administrator password from a Telnet or SSH session. You must have access to the local console connection.

To recover the network administrator password by power cycling the switch, follow these steps:

Step 1 Establish a terminal session on the console port of the supervisor module.

Step 2 Power cycle the switch.

Step 3 Press the Ctrl-B key sequence from the console port session when the switch begins the Cisco NX-OS software boot sequence to enter the boot prompt mode.

Ctrl-B

switch(boot)#

Step 4 Reset the network administrator password.

switch(boot)# configure terminal

switch(boot-config)# admin-password <new password>

switch(boot-config)# exit

switch(boot)#

Step 5 Display the bootflash: contents to locate the Cisco NX-OS software image file.

switch(boot)# dir bootflash:

Step 6 Load the Cisco NX-OS system software image.

In the following example, the system image filename is nx-os.bin:

switch(boot) # load bootflash:nx-os.bin

Step 7 Log in to the switch using the new administrator password.

switch login: admin

Password: <new password>

Step 8 Reset the new password to ensure that is it is also the SNMP password.

switch# configure terminal

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 9 Save the configuration.

switch# copy running-config startup-config

Using Ethanalyzer

Ethanalyzer is a Cisco NX-OS protocol analyzer tool based on the Wireshark (formerly Ethereal) open source code. Ethanalyzer is a command-line version of Wireshark that captures and decodes packets. You can use Ethanalyzer to troubleshoot your network and analyze the control-plane traffic.

To configure Ethanalyzer, use the following commands:

Command

Purpose

ethanalyzer local interface interface

Captures packets sent or received by the supervisor and provides detailed protocol information.

For the following commands, interface is inbound-hi (Inbound high priority interface), inbound-low (Inbound low priority interface), or mgmt (management interface).

ethanalyzer local interface interface brief

Captures packets sent or received by the supervisor and provides a summary of precool information.

ethanalyzer local interface interface limit-captured-frames

Limits the number of frames to capture.

ethanalyzer local interface interface limit-frame-size

Limits the length of the frame to capture.

ethanalyzer local interface interface capture-filter

Filters the types of packets to capture.

ethanalyzer local interface interface display-filter

Filters the types of captured packets to display.

ethanalyzer local interface interface write

Saves the captured data to a file.

ethanalyzer local read file

Opens a captured data file and analyzes it.

Ethanalyzer does not capture data traffic that Cisco NX-OS forwards in the hardware.

Ethanalyzer uses the same capture filter syntax as tcpdump. For more information, see the following URL:

http://www.tcpdump.org/tcpdump_man.html

For information on the syntax of the display filter, see the following URL:

http://wiki.wireshark.org/DisplayFilters

This example shows captured data (limited to four packets) on the management interface:

switch# ethanalyzer local interface mgmt brief limit-captured-frames 4

Capturing on eth0

2005-01-25 07:18:08.997132 10.193.24.42 -> 10.200.0.103 TELNET Telnet Data ...

2005-01-25 07:18:09.166266 10.200.0.103 -> 10.193.24.42 TCP 1235 > telnet [ACK] Seq=0 Ack=19 Win=64129 Len=0

2005-01-25 07:18:09.166830 10.193.24.42 -> 10.200.0.103 TELNET Telnet Data ...

2005-01-25 07:18:09.376250 10.200.0.103 -> 10.193.24.42 TCP 1235 > telnet [ACK] Seq=0 Ack=99 Win=64049 Len=0

4 packets captured

This example shows detailed captured data for one HSRP packet:

switch(config)# ethanalyzer local interface mgmt capture-filter "tcp port 23" limit-captured-frames 1

Capturing on eth0

Frame 1 (60 bytes on wire, 60 bytes captured)

Arrival Time: Jan 25, 2005 08:49:49.250719000

[Time delta from previous captured frame: 1106642989.250719000 seconds]

[Time delta from previous displayed frame: 1106642989.250719000 seconds]

[Time since reference or first frame: 1106642989.250719000 seconds]

Frame Number: 1

Frame Length: 60 bytes

Capture Length: 60 bytes

[Frame is marked: False]

[Protocols in frame: eth:ip:tcp]

Ethernet II, Src: 00:1a:a2:d2:d7:00 (00:1a:a2:d2:d7:00), Dst: 00:0d:ec:6d:81:00 (00:0d:ec:6d:81:00)

Destination: 00:0d:ec:6d:81:00 (00:0d:ec:6d:81:00)

Address: 00:0d:ec:6d:81:00 (00:0d:ec:6d:81:00)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Source: 00:1a:a2:d2:d7:00 (00:1a:a2:d2:d7:00)

Address: 00:1a:a2:d2:d7:00 (00:1a:a2:d2:d7:00)

.... ...0 .... .... .... .... = IG bit: Individual address (unicast)

.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

Type: IP (0x0800)

Trailer: 000000000000

Internet Protocol, Src: 10.200.0.103 (10.200.0.103), Dst: 10.193.24.42 (10.193.24.42)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 40

Identification: 0xa651 (42577)

Flags: 0x04 (Don't Fragment)

0... = Reserved bit: Not set

.1.. = Don't fragment: Set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 127

Protocol: TCP (0x06)

Header checksum: 0x2765 [correct]

[Good: True]

[Bad : False]

Source: 10.200.0.103 (10.200.0.103)

Destination: 10.193.24.42 (10.193.24.42)

Transmission Control Protocol, Src Port: 1288 (1288), Dst Port: telnet (23), Seq: 0, Ack: 0, Len: 0

Source port: 1288 (1288)

Destination port: telnet (23)

Sequence number: 0 (relative sequence number)

Acknowledgement number: 0 (relative ack number)

Header length: 20 bytes

Flags: 0x10 (ACK)

0... .... = Congestion Window Reduced (CWR): Not set

.0.. .... = ECN-Echo: Not set

..0. .... = Urgent: Not set

...1 .... = Acknowledgment: Set

.... 0... = Push: Not set

.... .0.. = Reset: Not set

.... ..0. = Syn: Not set

.... ...0 = Fin: Not set

Window size: 64334

Checksum: 0x934f [correct]

[Good Checksum: True]

[Bad Checksum: False]

1 packets captured

For more information on Wireshark, see the following URL: http://www.wireshark.org/docs/

Troubleshooting Fibre Channel

This section describes troubleshooting methods to resolve issues with Fibre Channel. This section includes the following topics:

- fctrace

- fcping

fctrace

The fctrace feature provides the following capabilities:

- Trace the route followed by data traffic.

- Compute inter-switch (hop-to-hop) latency.

You can invoke fctrace by providing the FC ID, the N port WWN, or the device alias of the destination.

The trace frame is routed normally through the network until it reaches the far edge of the fabric. When the frame reaches the edge of the fabric (the F port connected to the end node with the given port WWN or the FC ID), the frame is looped back (swapping the source ID and the destination ID) to the originator.

If the destination cannot be reached, the path discovery starts, which traces the path up to the point of failure.

Note The fctrace feature works only on TE ports. Make sure that only TE ports exist in the path to the destination. If there is an E port in the path, the fctrace frame is dropped by that switch. Also, fctrace times out in the originator, and path discovery does not start.

To perform the fctrace operation, perform one of these tasks:

Command

Purpose

switch# fctrace fcid 0xd70000 vsan 1

Route present for : 0xd70000

20:00:00:0b:46:00:02:82(0xfffcd5)

Timestamp Invalid.

20:00:00:05:30:00:18:db(0xfffcd7)

Timestamp Invalid.

20:00:00:05:30:00:18:db(0xfffcd7)

Invokes fctrace for the specified FC ID of the destination N port.

switch# fctrace pwwn 21:00:00:e0:8b:06:d9:1d vsan 1 timeout 5

Route present for : 21:00:00:e0:8b:06:d9:1d

20:00:00:0b:46:00:02:82(0xfffcd5)

Timestamp Invalid.

20:00:00:05:30:00:18:db(0xfffcd7)

Timestamp Invalid.

20:00:00:05:30:00:18:db(0xfffcd7)

Invokes fctrace using the pWWN of the destination N port.

By default the period to wait before timing out is 5 seconds, The range is from one through 10 seconds.

switch# fctrace device-alias disk1 v 1

Route present for : 22:00:00:0c:50:02:ce:f8

20:00:00:05:30:00:31:1e(0xfffca9)

Invokes fctrace using the device alias of the destination N port.

fcping

The fcping feature verifies reachability of a node by checking its end-to-end connectivity. You can invoke the fcping feature by providing the FC ID, the destination port WWN, or the device alias information.

To perform a fcping operation, perform this task:

Command

Purpose

Step 1

switch# fcping fcid 0xd70000 vsan 1

28 bytes from 0xd70000 time = 730 usec

28 bytes from 0xd70000 time = 165 usec

28 bytes from 0xd70000 time = 262 usec

28 bytes from 0xd70000 time = 219 usec

28 bytes from 0xd70000 time = 228 usec

5 frames sent, 5 frames received, 0 timeouts

Round-trip min/avg/max = 165/270/730 usec

Invokes fcping for the specified pWWN or the FC ID of the destination. By default, five frames are sent.

switch# fcping fcid 0xd70000 vsan 1 count 10

28 bytes from 0xd70000 time = 730 usec

28 bytes from 0xd70000 time = 165 usec

28 bytes from 0xd70000 time = 262 usec

28 bytes from 0xd70000 time = 219 usec

28 bytes from 0xd70000 time = 228 usec

28 bytes from 0xd70000 time = 230 usec

28 bytes from 0xd70000 time = 230 usec

28 bytes from 0xd70000 time = 225 usec

28 bytes from 0xd70000 time = 229 usec

28 bytes from 0xd70000 time = 183 usec

10 frames sent, 10 frames received, 0 timeouts

Round-trip min/avg/max = 165/270/730 usec

Sets the number of frames to be sent using the count option. The range is from 0 through 2147483647. A value of 0 causes the command to send frames forever.

switch# fcping fcid 0xd500b4 vsan 1 timeout 10

28 bytes from 0xd500b4 time = 1345 usec

...

5 frames sent, 5 frames received, 0 timeouts

Round-trip min/avg/max = 340/581/1345 usec

Sets the timeout value. The default period to wait is 5 seconds. The range is from 1 through 10 seconds.

switch# fcping device-alias disk1 vsan 1

28 bytes from 22:00:00:0c:50:02:ce:f8 time = 1883 usec

28 bytes from 22:00:00:0c:50:02:ce:f8 time = 493 usec

28 bytes from 22:00:00:0c:50:02:ce:f8 time = 277 usec

28 bytes from 22:00:00:0c:50:02:ce:f8 time = 391 usec

28 bytes from 22:00:00:0c:50:02:ce:f8 time = 319 usec

5 frames sent, 5 frames received, 0 timeouts

Round-trip min/avg/max = 277/672/1883 usec

Invokes fcping for the specified device alias of the destination.

Step 2

switch# fcping fcid 0x010203 vsan 1

No response from the N port.

switch# fcping pwwn 21:00:00:20:37:6f:db:dd vsan 1

28 bytes from 21:00:00:20:37:6f:db:dd time = 1454 usec

...

5 frames sent, 5 frames received, 0 timeouts

Round-trip min/avg/max = 364/784/1454 usec

Returns a “No response from the N port” message even when the N port is active. This is due to resource exhaustion at the N port.

Retry the command a few seconds later.

Verifying Switch Connectivity

You can verify connectivity to a destination switch.

Note The FC ID variable used in this procedure is the domain controller address; it is not a duplication of the domain ID.

To verify connectivity to a destination switch, perform this task:

Command

Purpose

Step 1

switch# show fcdomain domain-list vsan 200

Number of domains: 7

Domain ID WWN

--------- -----------------------

0x01(1) 20:c8:00:05:30:00:59:df [Principal]

0x02(2) 20:c8:00:0b:5f:d5:9f:c1

0x6f(111) 20:c8:00:05:30:00:60:df

0xda(218) 20:c8:00:05:30:00:87:9f [Local]

0x06(6) 20:c8:00:0b:46:79:f2:41

0x04(4) 20:c8:00:05:30:00:86:5f

0x6a(106) 20:c8:00:05:30:00:f8:e3

Displays the destination switch’s domain ID.

To obtain the domain controller address, concatenate the domain ID with FFFC. For example, if the domain ID is 0xda(218), the concatenated ID is 0xfffcda.

Step 2

switch# fcping fcid 0xFFFCDA vsan 200

28 bytes from 0xFFFCDA time = 298 usec

28 bytes from 0xFFFCDA time = 260 usec

28 bytes from 0xFFFCDA time = 298 usec

28 bytes from 0xFFFCDA time = 294 usec

28 bytes from 0xFFFCDA time = 292 usec

5 frames sent, 5 frames received, 0 timeouts

Round-trip min/avg/max = 260/288/298 usec

Verifies reachability of the destination switch by checking its end-to-end connectivity.

show tech-support Command

The show tech-support command is useful when collecting a large amount of information about the switch for troubleshooting purposes. The output of this command can be provided to technical support representatives when reporting a problem.

The show tech-support command displays the output of several show commands at once. The output from this command varies depending on your configuration. Use the show tech-support command in EXEC mode to display general information about the switch when reporting a problem.

You can choose to have detailed information for each command. You can specify the output for a particular interface, module, or VSAN. Each command output is separated by line and the command precedes the output.

Note Explicitly set the terminal length command to 0 (zero) to disable auto-scrolling and enable manual scrolling. Use the show terminal command to view the configured the terminal size. After obtaining the output of this command, remember to reset your terminal length as required.

Tip You can save the output of this command to a file by appending > (left arrow) and the filename to the show tech-support command. If you save this file, verify you have sufficient space to do so—each of these files may take about 1.8 MB. However, you can zip this file using the gzip filename command. Copy the zipped file to the required location using the copy command and unzip the file using the gunzip command.

The default output of the show tech-support command includes the output of the following commands:

- show switchname

- show system uptime

- show interface mgmt0

- show interface mgmt1

- show system resources

- show version

- dir bootflash:

- show inventory

- show diagnostic result all

- show logging log

- show module

- show environment

- show sprom backplane

- show clock

- show callhome

- show cfs application

- show cfs lock

- show snmp

- show interface brief

- show interface

- show running-config

- show startup-config

- show ip route

- show arp

- show monitor session all

- show accounting log

- show process

- show process cpu

- show process log

- show process memory

- show processes log details

- show logging log

- show license host-id

- show license

- show license usage

- show system reset-reason

- show logging nvram

- show install all status

- show install all failure-reason

- show system internal log install

- show system internal log install details

- show cores

- show topology

- show kernel internal aipc

- show tech-support acl

- show vlan

- show vlan access-map

- show mac-address-table

- show spanning-tree summary

- show spanning-tree active

- show interface trunk

- show aclmgr status

- show aclmgr internal dictionaries

- show aclmgr internal log

- show aclmgr internal ppf

- show aclmgr internal state-cache

- show access-lists

- show platform software ethpm internal info all

- show object-group

- show logging onboard obfl-logs

show tech-support brief Command

Use the show tech-support brief command to obtain a quick, condensed review of the switch configurations. This command provides a summary of the current running state of the switch (see the following example).

The show tech-support brief command is useful when collecting information about the switch for troubleshooting purposes. The output of this command can be provided to technical support representatives when reporting a problem.

Tip You can save the output of this command to a file by appending > (left arrow) and the filename to the show tech-support brief command.

This example shows how to display a condensed view of the switch configurations:

switch# show tech-support brief

Switch Name : switch

Switch Type :

Kickstart Image : 4.0(0) bootflash:///nuova-or-kickstart-nsg.4.0.0.001.bin

System Image : 4.0(0) bootflash:/nuova-or-system-nsg.4.0.0.001.binnms-or-47

IP Address/Mask : 172.16.24.47/24

Switch WWN : 20:00:00:0d:ec:6b:cd:c0

No of VSANs : 1

Configured VSANs : 1

VSAN 1: name:VSAN0001, state:active, interop mode:default

domain id:0xa6(166), WWN:20:01:00:0d:ec:6b:cd:c1 [Principal]

active-zone:<NONE>, default-zone:deny

-------------------------------------------------------------------------------

Interface Vsan Admin Admin Status SFP Oper Oper Port

Mode Trunk Mode Speed Channel

Mode (Gbps)

-------------------------------------------------------------------------------

fc3/1 1 auto on down swl -- --

fc3/2 1 auto on sfpAbsent -- -- --

fc3/3 1 auto on down swl -- --

fc3/4 1 auto on sfpAbsent -- -- --

fc3/5 1 auto on down swl -- --

fc3/6 1 auto on sfpAbsent -- -- --

fc3/7 1 auto on down swl -- --

fc3/8 1 auto on down swl -- --

-------------------------------------------------------------------------------

Interface Status IP Address Speed MTU Port

Channel

-------------------------------------------------------------------------------

Ethernet1/1 sfpIsAbsen -- -- 1500 --

Ethernet1/2 sfpIsAbsen -- -- 1500 --

Ethernet1/3 up -- 10000 1500 --

Ethernet1/4 sfpIsAbsen -- -- 1500 --

Ethernet1/5 sfpIsAbsen -- -- 1500 --

Ethernet1/6 sfpIsAbsen -- -- 1500 --

Ethernet1/7 sfpIsAbsen -- -- 1500 --

Ethernet1/8 sfpIsAbsen -- -- 1500 --

Ethernet1/9 sfpIsAbsen -- -- 1500 --

Ethernet1/10 sfpIsAbsen -- -- 1500 --

Ethernet1/11 sfpIsAbsen -- -- 1500 --

Ethernet1/12 sfpIsAbsen -- -- 1500 --

Ethernet1/13 sfpIsAbsen -- -- 1500 --

Ethernet1/14 sfpIsAbsen -- -- 1500 --

Ethernet1/15 notConnect -- -- 1500 --

Ethernet1/16 sfpIsAbsen -- -- 1500 --

Ethernet1/17 sfpIsAbsen -- -- 1500 --

Ethernet1/18 sfpIsAbsen -- -- 1500 --

Ethernet1/19 notConnect -- -- 1500 --

Ethernet1/20 sfpIsAbsen -- -- 1500 --

Ethernet1/21 sfpIsAbsen -- -- 1500 --

Ethernet1/22 sfpIsAbsen -- -- 1500 --

Ethernet1/23 sfpIsAbsen -- -- 1500 --

Ethernet1/24 sfpIsAbsen -- -- 1500 --

Ethernet1/25 sfpIsAbsen -- -- 1500 --

Ethernet1/26 sfpIsAbsen -- -- 1500 --

Ethernet1/27 sfpIsAbsen -- -- 1500 --

Ethernet1/28 sfpIsAbsen -- -- 1500 --

Ethernet1/29 sfpIsAbsen -- -- 1500 --

Ethernet1/30 sfpIsAbsen -- -- 1500 --

Ethernet1/31 sfpIsAbsen -- -- 1500 --

Ethernet1/32 sfpIsAbsen -- -- 1500 --

Ethernet1/33 sfpIsAbsen -- -- 1500 --

Ethernet1/34 sfpIsAbsen -- -- 1500 --

Ethernet1/35 up -- 10000 1500 --

Ethernet1/36 sfpIsAbsen -- -- 1500 --

Ethernet1/37 sfpIsAbsen -- -- 1500 --

Ethernet1/38 sfpIsAbsen -- -- 1500 --

Ethernet1/39 sfpIsAbsen -- -- 1500 --

Ethernet1/40 sfpIsAbsen -- -- 1500 --

-------------------------------------------------------------------------------

Interface Status IP Address Speed MTU

-------------------------------------------------------------------------------

mgmt0 up 172.16.24.47 100 1500

show tech-support fc Command

Use the show tech-support fc command to obtain information about the FC configuration on your switch.

The output of the show tech-support fc command includes the output of the following commands:

- show interface brief

- show interface

- show port internal info all

- show port internal event-history lock

- show port internal event-history msgs

- show port internal event-history errors

- show port internal mem-stats detail

- show san-port-channel internal event-history all

- show san-port-channel internal event-history errors

- show san-port-channel internal event-history msgs

- show san-port-channel internal event-history lock

- show san-port-channel internal mem-stats detail

- show san-port-channel usage

- show san-port-channel summary

- show san-port-channel consistency detail

- show tech-support device-alias

- show fcdomain domain-list

- show tech-support fcns

- show fcns database vsan 1-4093

- show fcns database detail vsan 1-4093

- show fcns database local vsan 1-4093

- show fcns database local detail vsan 1-4093

- show fcns statistics vsan 1-4093

- show fcns statistics detail vsan 1-4093

- show fcns internal info vsan 1-4093

- show fcns internal event-history

- show fcns internal event-log

- show fcroute unicast

- show fcs database

- show fcs ie

- show fctimer

- show flogi database

- show flogi internal info

- show fspf

- show fspf database

- show tech-support rscn

- show rscn internal vsan 1-4093

- show rscn internal event-history

- show rscn internal mem-stats detail

- show rscn internal session-history vsan 1-4093

- show rscn internal merge-history vsan 1-4093

- show rscn statistics vsan 1-4093

- show rscn scr-table vsan 1-4093

- show rscn session status vsan 1-4093

- show vsan

- show vsan membership

- show tech-support zone

- show zone status vsan 1-4093

- show zoneset active vsan 1-4093

- show zoneset vsan 1-4093

- show zone vsan 1-4093

- show fcalias vsan 1-4093

- show zone-attribute-group vsan 1-4093

- show zone policy vsan 1-4093

- show zoneset pending active vsan 1-4093

- show zoneset pending vsan 1-4093

- show zone pending vsan 1-4093

- show zone pending active vsan 1-4093

- show fcalias pending vsan 1-4093

- show zone policy pending vsan 1-4093

- show zone pending-diff vsan 1-4093

- show zone analysis active vsan 1-4093

- show zone analysis vsan 1-4093

- show zone ess vsan 1-4093

- show zone internal vsan 1-4093

- show zone internal change event-history vsan 1-4093

- show zone internal ifindex-table vsan 1-4093

- show zone internal merge event-history vsan 1-4093

- show zone internal event-history

- show zone internal event-history errors

- show zone internal tcam event-history vsan 1-4093

- show zone statistics vsan 1-4093

- show system default zone

- show zone internal ddas-table

- show zone internal sdv-table vsan 1-4093

- show zone internal mem-stats

- show zone internal mem-stats detail

- show zone internal transit-table received vsan 1-4093

- show zone internal transit-table forwarded vsan 1-4093

- show zone internal transit-table rejected vsan 1-4093

Tip You can save the output of this command to a file by appending > (left arrow) and the filename to the show tech-support zone command.

show tech-support platform Command

Use the show tech-support platform command to obtain information about the platform configuration of your switch.

The output of the show tech-support platform command includes the output of the following commands:

- show platform fwm mem-stats detail

- show platform fwm info global

- show platform fwm info pif all verbose

- show platform fwm info lif all verbose

- show platform fwm info vlan all verbose

- show platform fwm info error stats

- show platform fwm info error history

- show platform fwm info stm-stats

- show platform fwm info pc all verbose

- show platform fwm info ppf

- show platform fwm info pss all

- show platform hardware fwm info vlan all

- show platform hardware fwm info pif all

- show platform hardware fwm info lif all

- show platform hardware fwm info global

- show platform software zschk internal info

- show platform software zschk internal msgs

- show platform software statsclient msgs

- show hardware internal gatos detail

- show hardware internal gatos all-ports detail

- show hardware internal altos detail

- show hardware internal altos event-history errors

- show hardware internal altos event-history messages

- show platform fcfib fcflow

- show platform fcfib event-history all

- show platform fcfib unicasts

- show platform fcfib unicasts forwarding-configuration

- show platform fcfib vsan

- show platform fcfib san-port-channel

- show platform software fcfib devices

- show platform software fcfib multipath

- show platform software fcfib vsanidxtable

- show platform software fcfib domainidxtable

- show platform hardware fcfib pathselecttable

- show platform hardware fcfib pathselecttable all

- show platform software fcfib fctable-check

- show fc2 internal event-history errors

- show system internal liod liod_db

- show system internal liod queues

- show system internal liod state

- show system internal liod time_db

- show system internal rib domain

- show system internal rib system-attributes

- show system internal rib unicast

- show system internal rib vsan-attributes

- show system internal fcfwd fwidxmap if_index

- show system internal fcfwd idxmap interface-to-port

- show system internal fcfwd pcmap

- show platform afm info global

- show platform afm info attachment brief

- show platform afm info group-cfg all

- show platform afm info lop all

- show platform software altos detail

- show platform software altos event-history errors

- show platform software altos event-history msgs

- show platform software altos ports all

- show platform hardware altos counters all

- show platform hardware altos counters interrupts all

- show platform hardware altos interrupts all detail

Default Settings

Table 1-1 lists the default settings for the features included in this chapter.

Table 1-1 Default Settings for Troubleshooting Features

Parameters

Default

Timeout period to invoke fctrace

5 seconds

Number of frame sent by the fcping feature

5 frames

Remote capture connection protocol

TCP

Remote capture connection mode

Passive

Local capture frame limits

10 frames

FC ID allocation mode

Auto mode

Configuring and Managing VSANs

You can achieve higher security and greater stability in Fibre Channel fabrics by using virtual SANs (VSANs). VSANs provide isolation among devices that are physically connected to the same fabric. With VSANs you can create multiple logical SANs over a common physical infrastructure. Each VSAN can contain up to 239 switches and has an independent address space that allows identical Fibre Channel IDs (FC IDs) to be used simultaneously in different VSANs. This chapter includes the following sections:

- Information About VSANs

- Configuring VSANs

- Displaying Static VSAN Configuration

- Default Settings

Information About VSANs

A VSAN is a virtual storage area network (SAN). A SAN is a dedicated network that interconnects hosts and storage devices primarily to exchange SCSI traffic. In SANs you use the physical links to make these interconnections. A set of protocols run over the SAN to handle routing, naming, and zoning. You can design multiple SANs with different topologies.

This section describes VSANs and includes the following topics:

- VSAN Topologies

- VSAN Advantages

- VSANs Versus Zones

VSAN Topologies

With the introduction of VSANs, the network administrator can build a single topology containing switches, links, and one or more VSANs. Each VSAN in this topology has the same operation and property of a SAN. A VSAN has the following additional features:

- Multiple VSANs can share the same physical topology.

- The same Fibre Channel IDs (FC IDs) can be assigned to a host in another VSAN, which increases VSAN scalability.

- Every instance of a VSAN runs all required protocols such as FSPF, domain manager, and zoning.

- Fabric-related configurations in one VSAN do not affect the associated traffic in another VSAN.

- Events causing traffic disruptions in one VSAN are contained within that VSAN and are not propagated to other VSANs.

Figure 1-1 shows a fabric with three switches, one on each floor. The geographic location of the switches and the attached devices is independent of their segmentation into logical VSANs. No communication between VSANs is possible. Within each VSAN, all members can talk to one another.

Figure 1-1 Logical VSAN Segmentation

Figure 1-2 shows a physical Fibre Channel switching infrastructure with two defined VSANs: VSAN 2 (dashed) and VSAN 7 (solid). VSAN 2 includes hosts H1 and H2, application servers AS2 and AS3, and storage arrays SA1 and SA4. VSAN 7 connects H3, AS1, SA2, and SA3.

The application servers or storage arrays can be connected to the switch using Fibre Channel or virtual Fibre Channel interfaces. A VSAN can include a mixture of Fibre Channel and virtual Fibre Channel interfaces.

Figure 1-2 Example of Two VSANs

The four switches in this network are interconnected by VSAN trunk links that carry both VSAN 2 and

VSAN 7 traffic. You can configure a different inter-switch topology for each VSAN. In Figure 1-2, the inter-switch topology is identical for VSAN 2 and VSAN 7.

Without VSANs, a network administrator would need separate switches and links for separate SANs. By enabling VSANs, the same switches and links may be shared by multiple VSANs. VSANs allow SANs to be built on port granularity instead of switch granularity. Figure 1-2 illustrates that a VSAN is a group of hosts or storage devices that communicate with each other using a virtual topology defined on the physical SAN.

The criteria for creating such groups differ based on the VSAN topology:

- VSANs can separate traffic based on the following requirements:

– Different customers in storage provider data centers

– Production or test in an enterprise network

– Low and high security requirements

– Backup traffic on separate VSANs

– Replicating data from user traffic

- VSANs can meet the needs of a particular department or application.

VSAN Advantages

VSANs offer the following advantages:

- Traffic isolation—Traffic is contained within VSAN boundaries and devices reside only in one VSAN ensuring absolute separation between user groups, if desired.

- Scalability—VSANs are overlaid on top of a single physical fabric. The ability to create several logical VSAN layers increases the scalability of the SAN.

- Per VSAN fabric services—Replication of fabric services on a per VSAN basis provides increased scalability and availability.

- Redundancy—Several VSANs created on the same physical SAN ensure redundancy. If one VSAN fails, redundant protection (to another VSAN in the same physical SAN) is configured using a backup path between the host and the device.

- Ease of configuration—Users can be added, moved, or changed between VSANs without changing the physical structure of a SAN. Moving a device from one VSAN to another only requires configuration at the port level, not at a physical level.

Up to 256 VSANs can be configured in a switch. Of these, one is a default VSAN (VSAN 1), and another is an isolated VSAN (VSAN 4094). User-specified VSAN IDs range from 2 to 4093.

VSANs Versus Zones

Zones are always contained within a VSAN. You can define multiple zones in a VSAN.

Because two VSANs are equivalent to two unconnected SANs, zone A on VSAN 1 is different and separate from zone A in VSAN 2. Table 1-1 lists the differences between VSANs and zones.

Table 1-1 VSAN and Zone Comparison

VSAN Characteristic

Zone Characteristic

VSANs equal SANs with routing, naming, and zoning protocols.

Routing, naming, and zoning protocols are not available on a per-zone basis.

VSANs limit unicast, multicast, and broadcast traffic.

Zones limit unicast traffic.

Membership is typically defined using the VSAN ID to F ports.

Membership is typically defined by the pWWN.

An HBA or a storage device can belong only to a single VSAN (the VSAN associated with the F port).

An HBA or storage device can belong to multiple zones.

VSANs enforce membership at each E port, source port, and destination port.

Zones enforce membership only at the source and destination ports.

VSANs are defined for larger environments (storage service providers).

Zones are defined for a set of initiators and targets not visible outside the zone.

VSANs encompass the entire fabric.

Zones are configured at the fabric edge.

Figure 1-3 shows the possible relationships between VSANs and zones. In VSAN 2, three zones are defined: zone A, zone B, and zone C. Zone C overlaps both zone A and zone B as permitted by Fibre Channel standards. In VSAN 7, two zones are defined: zone A and zone D. No zone crosses the VSAN boundary. Zone A defined in VSAN 2 is different and separate from zone A defined in VSAN 7.

Figure 1-3 VSANS with Zoning

Configuring VSANs

VSANs have the following attributes:

- VSAN ID—The VSAN ID identifies the VSAN as the default VSAN (VSAN 1), user-defined VSANs (VSAN 2 to 4093), and the isolated VSAN (VSAN 4094).

- State—The administrative state of a VSAN can be configured to an active (default) or suspended state. Once VSANs are created, they may exist in various conditions or states.

– The active state of a VSAN indicates that the VSAN is configured and enabled. By enabling a VSAN, you activate the services for that VSAN.

– The suspended state of a VSAN indicates that the VSAN is configured but not enabled. If a port is configured in this VSAN, it is disabled. Use this state to deactivate a VSAN without losing the VSAN’s configuration. All ports in a suspended VSAN are disabled. By suspending a VSAN, you can preconfigure all the VSAN parameters for the whole fabric and activate the VSAN immediately.

- VSAN name—This text string identifies the VSAN for management purposes. The name can be from 1 to 32 characters long and it must be unique across all VSANs. By default, the VSAN name is a concatenation of VSAN and a four-digit string representing the VSAN ID. For example, the default name for VSAN 3 is VSAN0003.

Note A VSAN name must be unique.

- Load-balancing attributes—These attributes indicate the use of the source-destination ID (src-dst-id) or the originator exchange OX ID (src-dst-ox-id, the default) for load-balancing path selection.

This section describes how to create and configure VSANs and includes the following topics:

- About VSAN Creation

- Creating VSANs Statically

- About Port VSAN Membership

- Assigning Static Port VSAN Membership

- Displaying VSAN Static Membership

- About the Default VSAN

- About the Isolated VSAN

- Displaying Isolated VSAN Membership

- Operational State of a VSAN

- About Static VSAN Deletion

- Deleting Static VSANs

- About Load Balancing

- Configuring Load Balancing

- About Interop Mode

About VSAN Creation

A VSAN is in the operational state if the VSAN is active and at least one port is up. This state indicates that traffic can pass through this VSAN. This state cannot be configured.

Creating VSANs Statically

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# vsan database

switch(config-vsan-db)#

Configures the database for a VSAN. Application specific VSAN parameters cannot be configured from this prompt.

Step 3

switch(config-vsan-db)# vsan vsan-id

Creates a VSAN with the specified ID if that VSAN does not exist already.

Step 4

switch(config-vsan-db)# vsan vsan-id name name

updated vsan 2

Updates the VSAN with the assigned name.

Step 5

switch(config-vsan-db)# vsan vsan-id suspend

Suspends the selected VSAN.

Step 6

switch(config-vsan-db)# no vsan vsan-id suspend

Negates the suspend command issued in the previous step.

Step 7

switch(config-vsan-db)# end

switch#

Returns you to EXEC mode.

About Port VSAN Membership

Port VSAN membership on the switch is assigned on a port-by-port basis. By default each port belongs to the default VSAN. You can assign VSAN membership to ports using one of two methods:

- Statically—Assigning VSANs to ports.

See the “Assigning Static Port VSAN Membership” section.

- Dynamically—Assigning VSANs based on the device WWN. This method is referred to as dynamic port VSAN membership (DPVM). Cisco Nexus 5000 Series switches do not support DPVM.

VSAN trunking ports have an associated list of VSANs that are part of an allowed list (see Chapter 1, “Configuring VSAN Trunking”).

Assigning Static Port VSAN Membership

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# vsan database

switch(config-vsan-db)#

Configures the database for a VSAN.

Step 3

switch(config-vsan-db)# vsan vsan-id

Creates a VSAN with the specified ID if that VSAN does not exist already.

Step 4

switch(config-vsan-db)# vsan vsan-id interface fc slot/port

or

switch(config-vsan-db)# vsan vsan-id interface vfc slot/port

Assigns the membership of the specified interface to the VSAN.

Step 5

switch(config-vsan-db)# vsan vsan-id interface vfc slot/port

Updates the membership information of the interface to reflect the changed VSAN.

switch(config-vsan-db)# no vsan vsan-id interface fc slot/port

Removes the interface from the VSAN.

Displaying VSAN Static Membership

To display the VSAN static membership information, use the show vsan membership command.

Displays Static Membership Information for a Specified Interface

switch # show vsan membership interface fc2/1

fc2/1

vsan:1

allowed list:1-4093

About the Default VSAN

The factory settings for switches in the Cisco Nexus 5000 Series have only the default VSAN 1 enabled. We recommend that you do not use VSAN 1 as your production environment VSAN. If no VSANs are configured, all devices in the fabric are considered part of the default VSAN. By default, all ports are assigned to the default VSAN.

Note VSAN 1 cannot be deleted, but it can be suspended.

Note Up to 256 VSANs can be configured in a switch. Of these, one is a default VSAN (VSAN 1), and another is an isolated VSAN (VSAN 4094). User-specified VSAN IDs range from 2 to 4093.

About the Isolated VSAN

VSAN 4094 is an isolated VSAN. When a VSAN is deleted, all nontrunking ports are transferred to the isolated VSAN to avoid an implicit transfer of ports to the default VSAN or to another configured VSAN. This action ensures that all ports in the deleted VSAN become isolated (disabled).

Note When you configure a port in VSAN 4094 or move a port to VSAN 4094, that port is immediately isolated.

Caution Do not use an isolated VSAN to configure ports.

Note Up to 256 VSANs can be configured in a switch. Of these, one is a default VSAN (VSAN 1), and another is an isolated VSAN (VSAN 4094). User-specified VSAN IDs range from 2 to 4093.

Displaying Isolated VSAN Membership

The show vsan 4094 membership command displays all ports associated with the isolated VSAN.

Operational State of a VSAN

A VSAN is in the operational state if the VSAN is active and at least one port is up. This state indicates that traffic can pass through this VSAN. This state cannot be configured.

About Static VSAN Deletion

When an active VSAN is deleted, all of its attributes are removed from the running configuration. VSAN-related information is maintained by the system software as follows:

- VSAN attributes and port membership details are maintained by the VSAN manager. This feature is affected when you delete a VSAN from the configuration. When a VSAN is deleted, all the ports in that VSAN are made inactive and the ports are moved to the isolated VSAN. If the same VSAN is recreated, the ports do not automatically get assigned to that VSAN. You must explicitly reconfigure the port VSAN membership (see Figure 1-4).

Figure 1-4 VSAN Port Membership Details

- VSAN-based runtime (name server), zoning, and configuration (static routes) information is removed when the VSAN is deleted.

- Configured VSAN interface information is removed when the VSAN is deleted.

Note The allowed VSAN list is not affected when a VSAN is deleted (see Chapter 1, “Configuring VSAN Trunking”).

Any commands for a nonconfigured VSAN are rejected. For example, if VSAN 10 is not configured in the system, then a command request to move a port to VSAN 10 is rejected.

Deleting Static VSANs

To delete a VSAN and its various attributes, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# vsan database

switch(config-db)#

Configures the VSAN database.

Step 3

switch-config-db# vsan 2

switch(config-vsan-db)#

Places you in VSAN configuration mode.

Step 4

switch(config-vsan-db)# no vsan 5

switch(config-vsan-db)#

Deletes VSAN 5 from the database and switch.

Step 5

switch(config-vsan-db)# end

switch#

Places you in EXEC mode.

About Load Balancing

Load-balancing attributes indicate the use of the source-destination ID (src-dst-id) or the originator exchange OX ID (src-dst-ox-id, the default) for load-balancing path selection.

Configuring Load Balancing

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# vsan database

switch(config-vsan-db)#

Enters VSAN database configuration submode

Step 3

switch(config-vsan-db)# vsan vsan-id

Specifies an existing VSAN.

Step 4

switch(config-vsan-db)# vsan vsan-id loadbalancing src-dst-id

Enables the load-balancing guarantee for the selected VSAN and directs the switch to use the source and destination ID for its path selection process.

switch(config-vsan-db)# no vsan vsan-id loadbalancing src-dst-id

Negates the command entered in the previous step and reverts to the default values of the load-balancing parameters.

switch(config-vsan-db)# vsan vsan-id loadbalancing src-dst-ox-id

Changes the path selection setting to use the source ID, the destination ID, and the OX ID (default).

Step 5

switch(config-vsan-db)# vsan vsan-id suspend

Suspends the selected VSAN.

Step 6

switch(config-vsan-db)# no vsan vsan-id suspend

Negates the suspend command entered in the previous step.

Step 7

switch(config-vsan-db)# end

switch#

Returns you to EXEC mode.

About Interop Mode

Interoperability enables the products of multiple vendors to connect with each other. Fibre Channel standards guide vendors to create common external Fibre Channel interfaces. For additional information, see the “Switch Interoperability” section.

Displaying Static VSAN Configuration

The following example shows how to display information about a specific VSAN:

switch# show vsan 100

...

The following example shows how to display VSAN usage:

switch# show vsan usage

4 vsan configured

configured vsans:1-4

vsans available for configuration:5-4093

The following example shows how to display all VSANs:

switch# show vsan

Default Settings

Table 1-2 Default VSAN Parameters

Parameters

Default

Default VSAN

VSAN 1.

State

Active state.

Name

Concatenation of VSAN and a four-digit string representing the VSAN ID. For example, VSAN 3 is VSAN0003.

Load-balancing attribute

Configuring and Managing Zones

Zoning enables you to set up access control between storage devices or user groups. If you have administrator privileges in your fabric, you can create zones to increase network security and to prevent data loss or corruption. Zoning is enforced by examining the source-destination ID field.

Advanced zoning capabilities specified in the FC-GS-4 and FC-SW-3 standards are supported. You can use either the existing basic zoning capabilities or the advanced, standards-compliant zoning capabilities.

This chapter includes the following sections:

- Information About Zoning

- Configuring Zones

- Zone Sets

- Zone Set Distribution

- Zone Set Duplication

- Verifying Zone Information

- Enhanced Zoning

- Compacting the Zone Database

- Zone and Zone Set Analysis

- Default Settings

Note Table 1-1 lists the differences between zones and VSANs.

Information About Zoning

Zoning is described in the following topics:

- Zoning Features

- Zoning Example

- Zone Implementation

- Active and Full Zone Set Configuration Guidelines

Zoning Features

Zoning includes the following features:

- A zone consists of multiple zone members.

– Members in a zone can access each other; members in different zones cannot access each other.

– If zoning is not activated, all devices are members of the default zone.

– If zoning is activated, any device that is not in an active zone (a zone that is part of an active zone set) is a member of the default zone.

– Zones can vary in size.

– Devices can belong to more than one zone.

– A physical fabric can have a maximum of 16,000 members. This includes all VSANs in the fabric.

- A zone set consists of one or more zones.

– A zone set can be activated or deactivated as a single entity across all switches in the fabric.

– Only one zone set can be activated at any time.

– A zone can be a member of more than one zone set.

– A zone switch can have a maximum of 500 zone sets.

- Zoning can be administered from any switch in the fabric.

– When you activate a zone (from any switch), all switches in the fabric receive the active zone set. Additionally, full zone sets are distributed to all switches in the fabric, if this feature is enabled in the source switch.

– If a new switch is added to an existing fabric, zone sets are acquired by the new switch.

- Zone changes can be configured nondisruptively.

– New zones and zone sets can be activated without interrupting traffic on unaffected ports or devices.

- Zone membership can be specified using the following identifiers:

– Port world wide name (pWWN)—Specifies the pWWN of an N port attached to the switch as a member of the zone.

– Fabric pWWN—Specifies the WWN of the fabric port (switch port’s WWN). This membership is also referred to as port-based zoning.

– FC ID—Specifies the FC ID of an N port attached to the switch as a member of the zone.

– Interface and switch WWN (sWWN)—Specifies the interface of a switch identified by the sWWN. This membership is also referred to as interface-based zoning.

– Interface and domain ID—Specifies the interface of a switch identified by the domain ID.

– Domain ID and port number—Specifies the domain ID of a Cisco switch domain and additionally specifies a port belonging to a non-Cisco switch.

Note For N ports attached to the switch over a virtual Fibre Channel interface, you can specify zone membership using the pWWN of the N port, the FC ID of the N port, or the fabric pWWN of the virtual Fibre Channel interface.

- Default zone membership includes all ports or WWNs that do not have a specific membership association. Access between default zone members is controlled by the default zone policy.

- You can configure up to 8000 zones per VSAN and a maximum of 8000 zones for all VSANs on the switch.

Note Interface-based zoning only works with Cisco SAN switches. Interface-based zoning does not work for VSANs configured in interop mode.

Zoning Example

Figure 1-1 shows a zone set with two zones, zone 1 and zone 2, in a fabric. Zone 1 provides access from all three hosts (H1, H2, H3) to the data residing on storage systems S1 and S2. Zone 2 restricts the data on S3 to access only by H3. H3 resides in both zones.

Figure 1-1 Fabric with Two Zones

You can use other ways to partition this fabric into zones. Figure 1-2 shows another possibility. Assume that there is a need to isolate storage system S2 for the purpose of testing new software. To achieve this, zone 3 is configured, which contains only host H2 and storage S2. You can restrict access to only H2 and S2 in zone 3, and to H1 and S1 in zone 1.

Figure 1-2 Fabric with Three Zones

Zone Implementation

Cisco Nexus 5000 Series switches automatically support the following basic zone features (no additional configuration is required):

- Zones are contained in a VSAN.

- Hard zoning cannot be disabled.

- Name server queries are soft-zoned.

- Only active zone sets are distributed.

- Unzoned devices cannot access each other.

- A zone or zone set with the same name can exist in each VSAN.

- Each VSAN has a full database and an active database.

- Active zone sets cannot be changed, without activating a full zone database.

- Active zone sets are preserved across switch reboots.

- Changes to the full database must be explicitly saved.

- Zone reactivation (a zone set is active and you activate another zone set) does not disrupt existing traffic.

If required, you can additionally configure the following zone features:

- Propagate full zone sets to all switches on a per VSAN basis.

- Change the default policy for unzoned members.

- Interoperate with other vendors by configuring a VSAN in the interop mode. You can also configure one VSAN in the interop mode and another VSAN in the basic mode in the same switch without disrupting each other.

- Bring E ports out of isolation.

Active and Full Zone Set Configuration Guidelines

Before configuring a zone set, consider the following guidelines:

- Each VSAN can have multiple zone sets but only one zone set can be active at any given time.

- When you create a zone set, that zone set becomes a part of the full zone set.

- When you activate a zone set, a copy of the zone set from the full zone set is used to enforce zoning, and is called the active zone set. An active zone set cannot be modified. A zone that is part of an active zone set is called an active zone.

- The administrator can modify the full zone set even if a zone set with the same name is active. However, the modification will be enforced only upon reactivation.

- When the activation is done, the active zone set is automatically stored in persistent configuration. This enables the switch to preserve the active zone set information across switch resets.

- All other switches in the fabric receive the active zone set so they can enforce zoning in their respective switches.

- Hard and soft zoning are implemented using the active zone set. Modifications take effect during zone set activation.

- An FC ID or Nx port that is not part of the active zone set belongs to the default zone and the default zone information is not distributed to other switches.

Note If one zone set is active and you activate another zone set, the currently active zone set is automatically deactivated. You do not need to explicitly deactivate the currently active zone set before activating a new zone set.

Figure 1-3 shows a zone being added to an activated zone set.

Figure 1-3 Active and Full Zone Sets

Configuring Zones

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zone name zone-name vsan vsan-id

switch(config-zone)#

Configures a zone in the specified VSAN.

Note All alphanumeric characters or one of the following symbols ($, -, ^, _) are supported.

Step 3

switch(config-zone)# member type value

pWWN example:

switch(config-zone)# member pwwn pwwn-id

Fabric pWWN example:

switch(config-zone)# member fwwn fwwn-id

FC ID example:

switch(config-zone)# member fcid fcid

FC alias example:

switch(config-zone)# member fcalias Payroll

Domain ID example:

switch(config-zone)# member domain-id domain-id portnumber number

Local sWWN interface examples:

switch(config-zone)# member interface type slot/port

Remote sWWN interface example:

switch(config-zone)# member interface type slot/port swwn swwn-id

Domain ID interface example:

switch(config-zone)# member interface fc slot/port domain-id domain-id

) to obtain the required value in hex format.

Tip Use the show wwn switch command to retrieve the sWWN. If you do not provide a sWWN, the software automatically uses the local sWWN.

The following example shows how to configure zone members:

switch(config-zone)# member type value

pWWN example:

switch(config-zone)# member pwwn 10:00:00:23:45:67:89:ab

Fabric pWWN example:

switch(config-zone)# member fwwn 10:01:10:01:10:ab:cd:ef

FC ID example:

switch(config-zone)# member fcid 0xce00d1

FC alias example:

switch(config-zone)# member fcalias Payroll

Domain ID example:

switch(config-zone)# member domain-id 2 portnumber 23

Local sWWN interface examples:

switch(config-zone)# member interface fc 2/1

Remote sWWN interface example:

switch(config-zone)# member interface fc2/1 swwn 20:00:00:05:30:00:4a:de

Domain ID interface example:

switch(config-zone)# member interface fc2/1 domain-id 25

Zone Sets

This section describes zone sets and includes the following topics:

- Activating a Zone Set

- About the Default Zone

- Configuring the Default Zone Access Permission

- About FC Alias Creation

- Creating FC Aliases

- Creating Zone Sets and Adding Member Zones

- Zone Enforcement

In Figure 1-4, two separate sets are created, each with its own membership hierarchy and zone members.

Figure 1-4 Hierarchy of Zone Sets, Zones, and Zone Members

Zones provide a method for specifying access control, while zone sets are a grouping of zones to enforce access control in the fabric. Either zone set A or zone set B can be activated (but not together).

Tip Zone sets are configured with the names of the member zones and the VSAN (if the zone set is in a configured VSAN).

Activating a Zone Set

Changes to a zone set do not take effect in a full zone set until you activate it.

To activate or deactivate an existing zone set, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# zoneset activate name zoneset-name vsan vsan-id

Activates the specified zone set.

switch(config)# no zoneset activate name zoneset-name vsan vsan-id

Deactivates the specified zone set.

About the Default Zone

Each member of a fabric (in effect a device attached to an Nx port) can belong to any zone. If a member is not part of any active zone, it is considered to be part of the default zone. Therefore, if no zone set is active in the fabric, all devices are considered to be in the default zone. Even though a member can belong to multiple zones, a member that is part of the default zone cannot be part of any other zone. The switch determines whether a port is a member of the default zone when the attached port comes up.

Note Unlike configured zones, default zone information is not distributed to the other switches in the fabric.

Traffic can either be permitted or denied among members of the default zone. This information is not distributed to all switches; it must be configured in each switch.

Note When the switch is initialized for the first time, no zones are configured and all members are considered to be part of the default zone. Members are not permitted to communicate with each other.

Configure the default zone policy on each switch in the fabric. If you change the default zone policy on one switch in a fabric, be sure to change it on all the other switches in the fabric.

Note The default settings for default zone configurations can be changed.

The default zone members are explicitly listed when the default policy is configured as permit or when a zone set is active. When the default policy is configured as deny, the members of this zone are not explicitly enumerated when you view the active zone set.

Configuring the Default Zone Access Permission

To permit or deny traffic to members in the default zone, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zone default-zone permit vsan vsan-id

Permits traffic flow to default zone members.

switch(config)# no zone default-zone permit vsan vsan-id

Denies (default) traffic flow to default zone members.

About FC Alias Creation

You can assign an alias name and configure an alias member using the following values:

- pWWN—The WWN of the N port is in hex format (for example, 10:00:00:23:45:67:89:ab).

- fWWN—The WWN of the fabric port name is in hex format (for example, 10:00:00:23:45:67:89:ab).

- FC ID—The N port ID is in 0xhhhhhh format (for example, 0xce00d1).

- Domain ID—The domain ID is an integer from 1 to 239. A mandatory port number of a non-Cisco switch is required to complete this membership configuration.

- Interface—Interface-based zoning is similar to port-based zoning because the switch interface is used to configure the zone. You can specify a switch interface as a zone member for both local and remote switches. To specify a remote switch, enter the remote switch WWN (sWWN) or the domain ID in the particular VSAN.

Tip The switch supports a maximum of 2048 aliases per VSAN.

Creating FC Aliases

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# fcalias name AliasSample vsan vsan-id

switch(config-fcalias)#

Configures an alias name (AliasSample).

Step 3

switch(config-fcalias)# member type value

pWWN example:

switch(config-fcalias)# | pwwn pwwn-id

fWWN example:

switch(config-fcalias)# | fwwn fwwn-id

FC ID example:

switch(config-fcalias)# | fcid 0x222222

Domain ID example:

switch(config-fcalias)# | domain-id domain-id portnumber number

Local sWWN interface example:

switch(config-fcalias)# | interface type slot/port

[ swwn | domain-id 25 ]

Configures a member for the specified fcalias (AliasSample) based on the type (pWWN, fabric pWWN, FC ID, domain ID, or interface) and value specified.

Note Multiple members can be specified on multiple lines.

switch(config)# fcalias name AliasSample vsan 3

switch(config-fcalias)# member type value

pWWN example:

switch(config-fcalias)# member pwwn 10:00:00:23:45:67:89:ab

fWWN example:

switch(config-fcalias)# member fwwn 10:01:10:01:10:ab:cd:ef

FC ID example:

switch(config-fcalias)# member fcid 0x222222

Domain ID example:

switch(config-fcalias)# member domain-id 2 portnumber 23

Local sWWN interface example:

switch(config-fcalias)# member interface fc2/1

Remote sWWN interface example:

switch(config-fcalias)# member interface fc2/1 swwn 20:00:00:05:30:00:4a:de

Domain ID interface example:

switch(config-fcalias)# member interface fc2/1 domain-id 25

Creating Zone Sets and Adding Member Zones

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zoneset name zoneset-name vsan vsan-id

switch(config-zoneset)#

Configures a zone set called Zoneset1.

Tip To activate a zone set, you must first create the zone and a zone set.

Step 3

switch(config-zoneset)# member name

Adds Zone1 as a member of the specified zone set (Zoneset1).

message:

Step 4

switch(config-zoneset)# zone name zone-name

switch(config-zoneset-zone)#

Adds a zone to the specified zone set.

Tip Execute this step only if you need to create a zone from a zone set prompt.

Step 5

switch(config-zoneset-zone)# member fcid fcid

switch(config-zoneset-zone)#

Adds a new member to the new zone.

Tip Execute this step only if you need to add a member to a zone from a zone set prompt.

Tip You do not have to copy the running configuration to the startup configuration to store the active zone set. However, you need to copy the running configuration to the startup configuration to explicitly store full zone sets.

Note Be sure you understand how device alias modes work before enabling them. See Chapter 1, “Distributing Device Alias Services” for details and requirements about device alias modes.

Zone Enforcement

Zoning can be enforced in two ways: soft and hard. Each end device (N port) discovers other devices in the fabric by querying the name server. When a device logs in to the name server, the name server returns the list of other devices that can be accessed by the querying device. If an N port does not know about the FC IDs of other devices outside its zone, it cannot access those devices.

In soft zoning, zoning restrictions are applied only during interaction between the name server and the end device. If an end device somehow knows the FC ID of a device outside its zone, it can access that device.

Hard zoning is enforced by the hardware on each frame sent by an N port. As frames enter the switch, source-destination IDs are compared with permitted combinations to allow the frame at wire speed. Hard zoning is applied to all forms of zoning.

Note Hard zoning enforces zoning restrictions on every frame, and prevents unauthorized access.

Cisco Nexus 5000 Series switches support both hard and soft zoning.

Zone Set Distribution

You can distribute full zone sets using one of two methods: one-time distribution using the zoneset distribute vsan command at the EXEC mode level or full zone set distribution using the zoneset distribute full vsan command at the configuration mode level. Table 1-1 lists the differences between the methods.

Table 1-1 Zone Set Distribution Differences

One-Time Distribution

zoneset distribute vsan Command

(EXEC Mode)

Full Zone Set Distribution

zoneset distribute full vsan Command

(Configuration Mode)

Distributes the full zone set immediately.

Does not distribute the full zone set immediately.

Does not distribute the full zone set information along with the active zone set during activation, deactivation, or merge process.

Remembers to distribute the full zone set information along with the active zone set during activation, deactivation, and merge processes.

This section describes zone set distribution and includes the following topics:

- Enabling Full Zone Set Distribution

- Enabling a One-Time Distribution

- About Recovering from Link Isolation

- Importing and Exporting Zone Sets

Enabling Full Zone Set Distribution

All switches in the Cisco Nexus 5000 Series distribute active zone sets when new E port links come up or when a new zone set is activated in a VSAN. The zone set distribution takes effect while sending merge requests to the adjacent switch or while activating a zone set.

To enable full zone set and active zone set distribution to all switches on a per VSAN basis, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zoneset distribute full vsan vsan-id

Enables sending a full zone set along with an active zone set.

Enabling a One-Time Distribution

You can perform a one-time distribution of inactive, unmodified zone sets throughout the fabric.

Note The one-time distribution of the full zone set is supported in interop 2 and interop 3 modes, and not in interop 1 mode.

Use the show zone status vsan vsan-id command to check the status of the one-time zone set distribution request.

switch# show zone status vsan 3

VSAN: 3 default-zone: permit distribute: active only Interop: 100

mode:basic merge-control:allow

session:none

hard-zoning:enabled

Default zone:

qos:none broadcast:disabled ronly:disabled

Full Zoning Database :

Zonesets:0 Zones:0 Aliases: 0

Active Zoning Database :

Name: nozoneset Zonesets:1 Zones:2

Status: Zoneset distribution completed at 04:01:06 Aug 28 2004

About Recovering from Link Isolation

When two switches in a fabric are merged using a TE or E port, these TE and E ports may become isolated when the active zone set databases are different between the two switches or fabrics. When a TE port or an E port become isolated, you can recover that port from its isolated state using one of three options:

- Import the neighboring switch’s active zone set database and replace the current active zone set (see Figure 1-5).

- Export the current database to the neighboring switch.

- Manually resolve the conflict by editing the full zone set, activating the corrected zone set, and then bringing up the link.

Figure 1-5 Importing and Exporting the Database

Importing and Exporting Zone Sets

switch# zoneset import interface fc slot/port vsan vsan-id

Imports the zone set from the adjacent switch connected through the specified interface for the VSAN .

switch# zoneset import interface fc slot/port vsan vsan-id

Imports the zone set from the adjacent switch connected through the specified interface for the VSAN range.

Step 2

switch# zoneset export vsan vsan-id

Exports the zone set to the adjacent switch connected through the specified VSAN.

switch# zoneset export vsan vsan-id

Exports the zone set to the adjacent switch connected through the specified range of VSANs.

Note Perform the import and export operations from a single switch. Importing from one switch and exporting from another switch can lead to isolation again.

Zone Set Duplication

You can make a copy and then edit it without altering the existing active zone set. You can copy an active zone set from the bootflash: directory, volatile: directory, or slot0 to one of the following areas:

- To the full zone set

- To a remote location (using FTP, SCP, SFTP, or TFTP)

The active zone set is not part of the full zone set. You cannot make changes to an existing zone set and activate it if the full zone set is lost or is not propagated.

Caution Copying an active zone set to a full zone set may overwrite a zone with the same name if it already exists in the full zone set database.

This section includes the following topics:

- Copying Zone Sets

- Renaming Zones, Zone Sets, and Aliases

- Cloning Zones, Zone Sets, FC Aliases, and Zone Attribute Groups

- Clearing the Zone Server Database

Copying Zone Sets

On Cisco Nexus 5000 Series switches, you cannot edit an active zone set. However, you can copy an active zone set to create a new zone set that you can edit.

switch# zone copy active-zoneset full-zoneset vsan vsan-id

Please enter yes to proceed.(y/n) [n]? y

Makes a copy of the active zone set in the specified VSAN to the full zone set.

switch# zone copy vsan vsan-id active-zoneset scp://guest@myserver/tmp/active_zoneset.txt

Copies the active zone in the specified VSAN to a remote location using SCP.

Renaming Zones, Zone Sets, and Aliases

To rename a zone, zone set, fcalias, or zone-attribute-group, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zoneset rename oldname newname vsan vsan-id

Renames a zone set in the specified VSAN.

switch(config)# zone rename oldname newname vsan vsan-id

Renames a zone in the specified VSAN.

switch(config)# fcalias rename oldname newname vsan vsan-id

Renames a fcalias in the specified VSAN.

switch(config)# zone-attribute-group rename oldname newname vsan vsan-id

Renames a zone attribute group in the specified VSAN.

Step 3

switch(config)# zoneset activate name newname

vsan vsan-id

Activates the zone set and updates the new zone name in the active zone set.

Cloning Zones, Zone Sets, FC Aliases, and Zone Attribute Groups

To clone a zone, zone set, fcalias, or zone-attribute-group, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zoneset clone oldname newname

vsan vsan-id

Clones a zone set in the specified VSAN.

switch(config)# zone clone oldname newname vsan number

Clones a zone in the specified VSAN.

switch(config)# fcalias clone oldname newname

vsan vsan-id

Clones a fcalias in the specified VSAN.

switch(config)# zone-attribute-group clone oldname newname vsan vsan-id

Clones a zone attribute group in the specified VSAN.

Step 3

switch(config)# zoneset activate name newname

vsan vsan-id

Activates the zone set and updates the new zone name in the active zone set.

Clearing the Zone Server Database

You can clear all configured information in the zone server database for the specified VSAN.

To clear the zone server database, use the following command:

switch# clear zone database vsan 2

Note After entering a clear zone database command, you must explicitly enter the copy running-config startup-config to ensure that the running configuration is used when the switch reboots.

Note Clearing a zone set only erases the full zone database, not the active zone database.

Verifying Zone Information

You can view any zone information by using the show command. If you request information for a specific object (for example, a specific zone, zone set, VSAN, or alias, or keywords such as brief or active), only information for the specified object is displayed.

The following example shows how to display zone information for all VSANs:

switch# show zone

The following example shows how to display zone information for a specific VSAN:

switch# show zone vsan 1

The following example shows how to display the configured zone sets for a range of VSANs:

switch# show zoneset vsan 2-3

The following example shows how to display the members of a specific zone:

switch# show zone name Zone1

The following example shows how to display fcalias configuration:

switch# show fcalias vsan 1

The following example shows how to display all zones to which a member belongs:

switch# show zone member pwwn 21:00:00:20:37:9c:48:e5

The following example shows how to display the number of control frames exchanged with other switches:

switch# show zone statistics

The following example shows how to display the active zone set:

switch# show zoneset active

The following example shows how to display the active zones:

switch# show zone active

The following example shows how to display the zone status:

switch# show zone status

Enhanced Zoning

The zoning feature complies with the FC-GS-4 and FC-SW-3 standards. Both standards support the basic zoning functionalities explained in the previous section and the enhanced zoning functionalities described in this section.

This section includes the following topics:

- About Enhanced Zoning

- Changing from Basic Zoning to Enhanced Zoning

- Changing from Enhanced Zoning to Basic Zoning

- Enabling Enhanced Zoning

- Modifying the Zone Database

- Releasing Zone Database Locks

- Merging the Database

- Configuring Zone Merge Control Policies

- Default Zone Policies

- Configuring System Default Zoning Settings

- Verifying Enhanced Zone Information

About Enhanced Zoning

Table 1-2 Advantages of Enhanced Zoning

Basic Zoning

Enhanced Zoning

Enhanced Zoning Advantages

Administrators can make simultaneous configuration changes. Upon activation, one administrator can overwrite another administrator’s changes.

Performs all configurations within a single configuration session. When you begin a session, the switch locks the entire fabric to implement the change.

One configuration session for the entire fabric to ensure consistency within the fabric.

If a zone is part of multiple zone sets, you create an instance of this zone in each zone set

References to the zone are used by the zone sets as required once you define the zone.

Reduced payload size as the zone is referenced. The size is more pronounced with bigger databases.

The default zone policy is defined per switch. To ensure smooth fabric operation, all switches in the fabric must have the same default zone setting.

Enforces and exchanges the default zone setting throughout the fabric.

Fabric-wide policy enforcement reduces troubleshooting time.

To retrieve the results of the activation on a per switch basis, the managing switch provides a combined status about the activation. It does not identify the failure switch.

Retrieves the activation results and the nature of the problem from each remote switch.

Enhanced error reporting eases the troubleshooting process

To distribute the zoning database, you must reactivate the same zone set. The reactivation may affect hardware changes for hard zoning on the local switch and on remote switches.

Implements changes to the zoning database and distributes it without reactivation.

Distribution of zone sets without activation avoids hardware changes for hard zoning in the switches.

The Cisco-specific zone member types (symbolic node name, and other types) may be used by other non-Cisco switches. During a merge, the Cisco-specific types can be misunderstood by the non-Cisco switches.

Provides a vendor ID along with a vendor-specific type value to uniquely identify a member type.

Unique vendor type.

The fWWN-based zone membership is only supported in Cisco interop mode.

Supports fWWN-based membership in the standard interop mode (interop mode 1).

The fWWN-based member type is standardized.

Changing from Basic Zoning to Enhanced Zoning

To change to the enhanced zoning mode from the basic mode, perform this task:

Step 1 Verify that all switches in the fabric are capable of working in the enhanced mode.

If one or more switches are not capable of working in enhanced mode, then your request to move to enhanced mode is rejected.

Step 2 Set the operation mode to enhanced zoning mode.

You will automatically start a session, acquire a fabric wide lock, distribute the active and full zoning database using the enhanced zoning data structures, distribute zoning policies and then release the lock. All switches in the fabric then move to the enhanced zoning mode.

Tip After moving from basic zoning to enhanced zoning, we recommend that you save the running configuration.

Changing from Enhanced Zoning to Basic Zoning

Cisco SAN switches allow you to change from enhanced zoning to basic zoning to enable you to downgrade and upgrade to other Cisco NX-OS releases.

To change to the basic zoning mode from the enhanced mode, perform this task:

Step 1 Verify that the active and full zone set do not contain any configuration that is specific to the enhanced zoning mode.

If such configurations exist, delete them before proceeding with this procedure. If you do not delete the existing configuration, the switch software automatically removes them.

Step 2 Set the operation mode to basic zoning mode.

Enabling Enhanced Zoning

By default, the enhanced zoning feature is disabled in all switches in the Cisco Nexus 5000 Series.

To enable enhanced zoning in a VSAN, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# zone mode enhanced vsan vsan-id

Set zoning mode command initiated. Check zone status

Enables enhanced zoning in the specified VSAN.

switch(config)# no zone mode enhanced vsan vsan-id

Set zoning mode command initiated. Check zone status

Disables enhanced zoning in the specified VSAN.

Modifying the Zone Database

Modifications to the zone database is done within a session. A session is created at the time of the first successful configuration command. On creation of a session, a copy of the zone database is created. Any changes done within the session are performed on this copy of the zoning database. These changes in the copy zoning database are not applied to the effective zoning database until you commit the changes. Once you apply the changes, the session is closed.

If the fabric is locked by another user and for some reason the lock is not cleared, you can force the operation and close the session. You must have permission (role) to clear the lock in this switch and perform the operation on the switch from where the session was originally created.

To commit or discard changes to the zoning database in a VSAN, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# zone commit vsan vsan-id

No pending info found

Applies the changes to the enhanced zone database and closes the session.

switch(config)# zone commit vsan vsan-id force

Forcefully applies the changes to the enhanced zone database and closes the session created by another user.

switch(config)# no zone commit vsan vsan-id

Discards the changes to the enhanced zone database and closes the session.

switch(config)# no zone commit vsan vsan-id force

Forcefully discards the changes to the enhanced zone database and closes the session created by another user.

Releasing Zone Database Locks

To release the session lock on the zoning database on the switches in a VSAN, use the no zone commit vsan command from the switch where the database was initially locked.

switch# configuration terminal

switch(config)# no zone commit vsan 2

If session locks remain on remote switches after using the no zone commit vsan command, you can use the clear zone lock vsan command on the remote switches.

switch# clear zone lock vsan 2

Note We recommend using the no zone commit vsan command first to release the session lock in the fabric. If that fails, use the clear zone lock vsan command on the remote switches where the session is still locked.

Merging the Database

Table 1-3 Database Zone Merge Status

Local Database

Adjacent Database

Merge Status

Results of the Merge

The databases contain zone sets with the same name1 but different zones, aliases, and attributes groups.

Successful.

The union of the local and adjacent databases.

The databases contains a zone, zone alias, or zone attribute group object with same name^1 but different members.

Failed.

ISLs are isolated.

Empty.

Contains data.

Successful.

The adjacent database information populates the local database.

Contains data.

Empty.

Successful.

The local database information populates the adjacent database.

1.In the enhanced zoning mode, the active zone set does not have a name in interop mode 1. The zone set names are only present for full zone sets.

The merge process operates as follows:

1. The software compares the protocol versions. If the protocol versions differ, then the ISL is isolated.

2. If the protocol versions are the same, then the zone policies are compared. If the zone policies differ, then the ISL is isolated.

3. If the zone merge options are the same, then the comparison is implemented based on the merge control setting.

a. If the setting is restrict, the active zone set and the full zone set should be identical. Otherwise, the link is isolated.

b. If the setting is allow, then the merge rules are used to perform the merge.

Configuring Zone Merge Control Policies

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# zone merge-control restrict vsan vsan-id

Configures a restricted merge control setting for this VSAN.

switch(config)# no zone merge-control restrict vsan vsan-id

Defaults to using the allow merge control setting for this VSAN.

switch(config)# zone commit vsan vsan-id

Commits the changes made to the specified VSAN.

Default Zone Policies

To permit or deny traffic in the default zone, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# zone default-zone permit vsan vsan-id

Permits traffic flow to default zone members.

switch(config)# no zone default-zone permit vsan vsan-id

Denies traffic flow to default zone members and reverts to factory default.

Step 3

switch(config)# zone commit vsan vsan-id

Commits the changes made to the specified VSAN.

Configuring System Default Zoning Settings

You can configure default settings for default zone policies and full zone distribution for new VSANs on the switch. To configure switch-wide default settings, perform this task:

Command

Purpose

Step 1

switch# configuration terminal

Enters configuration mode.

Step 2

switch(config)# system default zone default-zone permit

Configures permit as the default zoning policy for new VSANs on the switch.

switch(config)# no system default zone default-zone permit

Configures deny (default) as the default zoning policy for new VSANs on the switch.

Step 3

switch(config)# system default zone distribute full

Enables full zone database distribution as the default for new VSANs on the switch.

Step 4

switch(config)# no system default zone distribute full

Disables (default) full zone database distribution as the default for new VSANs on the switch. Only the active zone database is distributed.

Note Since VSAN 1 is the default VSAN and is always present on the switch, the system default zone commands have no effect on VSAN 1.

Verifying Enhanced Zone Information

The following example shows how to display the zone status for a specified VSAN:

switch# show zone status vsan 2

Compacting the Zone Database

You can delete excess zones and compact the zone database for the VSAN.

Note A merge failure occurs when a switch supports more than 2000 zones per VSAN but its neighbor does not. Also, zone set activation can fail if the switch has more than 2000 zones per VSAN and not all switches in the fabric support more than 2000 zones per VSAN.

switch# configuration terminal

switch(config)#

Enters configuration mode.

Step 2

switch(config)# no zone name zone-name vsan vsan-id

Deletes a zone to reduce the number of zones to 2000 or fewer.

Step 3

switch(config)# zone compact vsan vsan-id

Compacts the zone database for the specified VSAN to recover the zone ID released when a zone was deleted.

Zone and Zone Set Analysis

To better manage the zones and zone sets on your switch, you can display zone and zone set information using the show zone analysis command.

switch# show zone analysis active vsan 1

See the Cisco Nexus 5000 Series Switch Command Reference for the description of the information displayed in the command output.

Default Settings

Table 1-4 Default Basic Zone Parameters

Parameters

Default

Default zone policy

Denied to all members.

Full zone set distribute

The full zone set(s) is not distributed.

Enhanced zoning