Table of Contents

Preface chapter

New and changed information

overview

Configuring FIPS

Configuring Users and Common Role

Configuring Security Features on an External AAA Server

Configuring IPv4 and IPv6 Access Control Lists

Configuring Certificate Authorities and Digital Certificates

Configuring IPsec Network Security

Configuring FC-SP and DHCHAP

Configuring Port Security

Configuring Fabric Binding

Configuring Cisco TrustSec Fibre Channel Link Encryption

title

Preface

. 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 the Cisco MDS 9000 Family of multilayer directors and fabric switches.

Document Organization

This document is organized as follows:

Chapter

Title

Description

Provides an overview of the security features supported by the Cisco MDS 9000 Family NX-OS software.

Describes the configuration guidelines for FIPS and also how to enable FIPS mode and how to conduct FIPS self-tests.

Describes how to configure users and common roles.

Describes the AAA parameters, user profiles, and RADIUS authentication security options provided in all switches in the Cisco MDS 9000 Family and provides configuration information for these options.

Describes the IPv4 static routing feature and its use to route traffic between VSANs.

Describes how to interoperate with Certificate Authorities (CAs) and use digital certificates for secure, scalable communication.

Provides details on the digital certificates, IP Security Protocol (IPsec) open standards, and the Internet Key Exchange (IKE) protocol that it uses to handle protocol and algorithm negotiation.

Describes the DHCHAP protocol, an FC-SP protocol, that provides authentication between Cisco MDS 9000 Family switches and other devices.

Provides details on port security features that can prevent unauthorized access to a switch port in the Cisco MDS 9000 Family.

Describes the fabric binding security feature for VSANs, which ensures that ISLs are only enabled between specific switches.

Describes how the switch allows IP hosts to access Fibre Channel storage using the iSCSI protocol.

This document is organized as folows:

Chapter

Title

Description

Provides an overview of the security features supported by the Cisco MDS 9000 Family NX-OS software.

Describes the configuration guidelines for FIPS and also how to enable FIPS mode and how to conduct FIPS self-tests.

Describes how to configure users and common roles.

Describes the AAA parameters, user profiles, and RADIUS authentication security options provided in all switches in the Cisco MDS 9000 Family and provides configuration information for these options.

Describes the IPv4 static routing feature and its use to route traffic between VSANs.

Describes how to interoperate with Certificate Authorities (CAs) and use digital certificates for secure, scalable communication.

Provides details on the digital certificates, IP Security Protocol (IPsec) open standards, and the Internet Key Exchange (IKE) protocol that it uses to handle protocol and algorithm negotiation.

Describes the DHCHAP protocol, an FC-SP protocol, that provides authentication between Cisco MDS 9000 Family switches and other devices.

Provides details on port security features that can prevent unauthorized access to a switch port in the Cisco MDS 9000 Family.

Describes the fabric binding security feature for VSANs, which ensures that ISLs are only enabled between specific switches.

Describes how the switch allows IP hosts to access Fibre Channel storage using the iSCSI protocol.

Document Conventions

Command descriptions use these conventions:

Commands and keywords are in boldface.

Arguments for which you supply values are in italics.

Elements in square brackets are optional.

Optional alternative keywords are grouped in brackets and separated by vertical bars.

Screen examples use these conventions:

Terminal sessions and information the switch displays are in screen font.

Information you must enter is in boldface 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

The documentation set for the Cisco MDS 9000 Family includes the following documents. To find a document online, use the Cisco MDS NX-OS Documentation Locator at:

http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/roadmaps/doclocater.htm

Release Notes

- Cisco MDS 9000 Family Release Notes for Cisco MDS NX-OS Releases

- Cisco MDS 9000 Family Release Notes for MDS SAN-OS Releases

- Cisco MDS 9000 Family Release Notes for Cisco MDS 9000 EPLD Images

- Cisco DCNM Release Notes

Regulatory Compliance and Safety Information

- Regulatory Compliance and Safety Information for the Cisco MDS 9000 Family

Compatibility Information

- Cisco Data Center Interoperability Support Matrix

- Cisco MDS 9000 NX-OS Hardware and Software Compatibility Information and Feature Lists

- Cisco MDS 9000 Family Switch-to-Switch Interoperability Configuration Guide

Hardware Installation

- Cisco MDS 9500 Series Hardware Installation Guide

- Cisco MDS 9200 Series Hardware Installation Guide

- Cisco MDS 9100 Series Hardware Installation Guide

- Cisco MDS 9124 and Cisco MDS 9134 Multilayer Fabric Switch Quick Start Guide

Software Installation and Upgrade

- Cisco MDS 9000 NX-OS Software Upgrade and Downgrade Guide

Cisco NX-OS

- Cisco MDS 9000 Family NX-OS Licensing Guide

- Cisco MDS 9000 Family NX-OS Fundamentals Configuration Guide

- Cisco MDS 9000 Family NX-OS System Management Configuration Guide

- Cisco MDS 9000 Family NX-OS Interfaces Configuration Guide

- Cisco MDS 9000 Family NX-OS Fabric Configuration Guide

- Cisco MDS 9000 Family NX-OS Quality of Service Configuration Guide

- Cisco MDS 9000 Family NX-OS Security Configuration Guide

- Cisco MDS 9000 Family NX-OS IP Services Configuration Guide

- Cisco MDS 9000 Family NX-OS Intelligent Storage Services Configuration Guide

- Cisco MDS 9000 Family NX-OS High Availability and Redundancy Configuration Guide

- Cisco MDS 9000 Family NX-OS Inter-VSAN Routing Configuration Guide

- Cisco MDS 9000 Family Cookbook for Cisco MDS SAN-OS

Cisco DCNM

- Cisco DCNM Fundamentals Guide, Release 6.x

- Cisco DCNM Installation and Licensing Guide, Release 6.x

Cisco DCNM-SAN

- System Management Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Interfaces Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Fabric Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Quality of Service Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Security Configuration Guide, Cisco DCNM for SAN, Release 6.x

- IP Services Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Intelligent Storage Services Configuration Guide, Cisco DCNM for SAN, Release 6.x

- High Availability and Redundancy Configuration Guide, Cisco DCNM for SAN, Release 6.x

- Inter-VSAN Routing Configuration Guide, Cisco DCNM for SAN, Release 6.x

- SMI-S and Web Services Programming Guide, Cisco DCNM for SAN, Release 6.x

Command-Line Interface

- Cisco MDS 9000 Family Command Reference

Intelligent Storage Networking Services Configuration Guides

- Cisco MDS 9000 Family I/O Acceleration Configuration Guide

- Cisco MDS 9000 Family SANTap Deployment Guide

- Cisco MDS 9000 Family Data Mobility Manager Configuration Guide

- Cisco MDS 9000 Family Storage Media Encryption Configuration Guide

Troubleshooting and Reference

- Cisco MDS 9000 Family and Nexus 7000 Series System Messages Reference

- Cisco MDS 9000 Family SAN-OS Troubleshooting Guide

- Cisco MDS 9000 Family NX-OS MIB Quick Reference

- Cisco DCNM for SAN Database Schema Reference

Obtaining Documentation and Submitting a Service Request

, which also lists all new and revised Cisco technical documentation, at:

- 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.

New and Changed Information

The following table lists the New and Changed features for this guide.

Table 1 New and Changed Features

Feature

New or Changed Topics

Changed in Release

Where Documented

There are no changes since Release 5.2(1)

—

—

—

Security Overview

The Cisco MDS 9000 NX-OS software supports advanced security features that provide security within a Storage Area Network (SAN). These features protect your network against deliberate or unintentional disruptions from internal or external threats.

This chapter includes the following sections:

- FIPS

- Users and Common Roles

- RADIUS and TACACS+

- LDAP

- IP ACLs

- PKI

- IPsec

- FC-SP and DHCHAP

- Port Security

- Fabric Binding

- TrustSec Fibre Channel Link Encryption

FIPS

The Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, details the U.S. government requirements for cryptographic modules. FIPS 140-2 specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary. FIPS specifies certain crypto algorithms as secure, and it also identifies which algorithms should be used if a cryptographic module is to be called FIPS compliant.

For more information on configuring FIPS, see Chapter2, “Configuring FIPS”

Users and Common Roles

Role-based authorization limits access to switch operations by assigning users to roles. All management access within the Cisco MDS 9000 Family is based upon roles. Users are restricted to performing the management operations that are explicitly permitted, by the roles to which they belong.

For information on configuring users and common roles, see Chapter3, “Configuring Users and Common Role”

RADIUS and TACACS+

The authentication, authorization, and accounting (AAA) feature verifies the identity of, grants access to, and tracks the actions of users managing a switch. All Cisco MDS 9000 Family switches use RADIUS and TACACS+ protocols to provide solutions using remote AAA servers. This security feature provides a centralized user account management capability for AAA servers.

AAA uses security protocols to administer its security functions. If your router or access server is acting as a network access server, then the communication between your network access server and the RADIUS or TACACS+ security server is through AAA.

The chapters in this guide describe the following features:

- Switch management—A management security system that provides security to all management access methods, including the command-line interface (CLI) or Simple Network Management Protocol(SNMP).

- Switch AAA functionalities—A function by which you can configure AAA switch functionalities on any switch in the Cisco MDS 9000 Family, using the command-line interface (CLI) or Simple Network Management Protocol (SNMP).

- RADIUS—A distributed client and server system implemented through AAA that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.

- TACACS+—A security application implemented through AAA that provides a centralized validation of users who are attempting to gain access to a router or network access server. TACACS+ services are maintained in a database on a TACACS+ daemon that typically runs on a UNIX or Windows NT workstation. TACACS+ provides for separate and modular authentication, authorization, and accounting facilities.

LDAP

The Lightweight Directory Access Protocol (LDAP) provides centralized validation of users attempting to gain access to a Cisco NX-OS device. LDAP services are maintained in a database on an LDAP daemon typically running on a UNIX or Windows NT workstation. You must have access to and must configure an LDAP server before the configured LDAP features on your Cisco NX-OS device are available.

LDAP provides for separate authentication and authorization facilities. LDAP allows for a single access control server (the LDAP daemon) to provide each service authentication and authorization independently. Each service can be connected to 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 LDAP client and server protocol uses TCP (TCP port 389) for transport requirements. Cisco NX-OS devices provide centralized authentication using the LDAP protocol.

For information on configuring RADIUS and TACACS+, see Chapter4, “Configuring Security Features on an External AAA Server”

IP ACLs

IP access control lists (ACLs) provide basic network security on the out-of-band management Ethernet interface and the in-band IP management Interface. The Cisco MDS 9000 Family switches use IP ACLs to restrict traffic from unknown and untrusted sources and restrict network use based on user identity or device type.

For information on configuring IP ACLs, see Chapter 5, “Configuring IPv4 and IPv6 Access Control Lists”.

PKI

The Public Key Infrastructure (PKI) allows an MDS 9000 switch to obtain and use digital certificates for secure communication in the network. PKI support provides manageability and scalability for applications, such as IPsec, IKE, and SSH, that support digital certificates.

For information on configuring PKI, see Chapter6, “Configuring Certificate Authorities and Digital Certificates”

IPsec

IP Security (IPsec) protocol is a framework of open standards by the Internet Engineering Task Force (IETF) that provides data confidentiality, data integrity, and data origin authentication between participating peers. IPsec provides security services at the IP layer, including protecting one or more data flows between a pair of hosts, a pair of security gateways, or a security gateway and a host.

For information on configuring IPsec, see Chapter7, “Configuring IPsec Network Security”

FC-SP and DHCHAP

Fibre Channel Security Protocol (FC-SP) capabilities provide switch to switch and hosts to switch authentication to overcome security challenges for enterprise-wide fabrics. Diffie-Hellman Challenge Handshake Authentication Protocol (DHCHAP) is an FC-SP protocol that provides authentication between Cisco MDS 9000 Family switches and other devices. DHCHAP consists of the CHAP protocol combined with the Diffie-Hellman exchange.

With FC-SP, switches, storage devices, and hosts are able to prove their identity through a reliable and manageable authentication mechanism. With FC-SP, Fibre Channel traffic can be secured on a frame-by-frame basis to prevent snooping and hijacking, even over untrusted links. A consistent set of policies and management actions are propagated through the fabric to provide a uniform level of security across the entire fabric.

For more information on configuring FS-SP and DHCHAP, see Chapter8, “Configuring FC-SP and DHCHAP”

Port Security

The port security feature prevents unauthorized access to a switch port by binding specific world-wide names (WWNs) that have access to one or more given switch ports.

When port security is enabled on a switch port, all devices connecting to that port must be in the port security database and must be listed in the database as bound to a given port. If both of these criteria are not met, the port will not achieve an operationally active state and the devices connected to the port will be denied access to the SAN.

For information on configuring port security, see Chapter9, “Configuring Port Security”

Fabric Binding

The fabric binding feature ensures Inter-Switch Links (ISLs) are enabled only between specified switches in the fabric binding configuration. This feature helps prevent unauthorized switches from joining the fabric or disrupting the current fabric operations. This feature uses the Exchange Fabric Membership Data (EEMD) protocol to ensure that the list of authorized switches is identical in all of the switches in a fabric.

For information on configuring fabric binding, see Chapter10, “Configuring Fabric Binding”

TrustSec Fibre Channel Link Encryption

Cisco TrustSec Fibre Channel Link Encryption is an extension of the Fibre Channel-Security Protocol (FC-SP) feature and uses the existing FC-SP architecture to provide integrity and confidentiality of transactions. Encryption is added to the peer authentication capability to provide security and prevent unwanted traffic interception. Peer authentication is implemented according to the FC-SP standard using the Diffie-Hellman Challenge Handshake Authentication Protocol (DHCHAP) protocol.

For information on configuring TrustSec Fibre Channel Link Encryption, see Chapter11, “Configuring Cisco TrustSec Fibre Channel Link Encryption”

Configuring FIPS

The Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, details the U.S. government requirements for cryptographic modules. FIPS 140-2 specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary.

FIPS specifies certain crypto algorithms as secure, and it also identifies which algorithms should be used if a cryptographic module is to be called FIPS compliant.

Note Cisco MDS SAN-OS Release 3.1(1) and NX-OS Release 4.1(1b) or later implements FIPS features and is currently in the certification process with the U.S. government, but it is not FIPS compliant at this time.

This chapter includes the following topics:

- Information About FIPS Self-Tests

- Guidelines and Limitations

- Enabling FIPS Mode

- Verifying FIPS Configuration

- Field Descriptions for FIPS

Information About FIPS Self-Tests

A cryptographic module must perform power-up self-tests and conditional self-tests to ensure that it is functional.

Note FIPS power-up self-tests automatically run when FIPS mode is enabled by entering the fips mode enable command. A switch is in FIPS mode only after all self-tests are successfully completed. If any of the self-tests fail, then the switch is rebooted.

Power-up self-tests run immediately after FIPS mode is enabled. A cryptographic algorithm test using a known answer must be run for all cryptographic functions for each FIPS 140-2-approved cryptographic algorithm implemented on the Cisco MDS 9000 Family.

Using a known-answer test (KAT), a cryptographic algorithm is run on data for which the correct output is already known, and then the calculated output is compared to the previously generated output. If the calculated output does not equal the known answer, the known-answer test fails.

Conditional self-tests must be run when an applicable security function or operation is invoked. Unlike the power-up self-tests, conditional self-tests are executed each time their associated function is accessed.

Conditional self-tests include the following:

- Pair-wise consistency test—This test is run when a public-private key-pair is generated.

- Continuous random number generator test—This test is run when a random number is generated.

Both of these tests automatically run when a switch is in FIPS mode.

Guidelines and Limitations

Follow these guidelines before enabling FIPS mode:

- Make your passwords a minimum of eight characters in length.

- Disable Telnet. Users should log in using SSH only.

- Disable remote authentication through RADIUS/TACACS+. Only users local to the switch can be authenticated.

- Disable SNMP v1 and v2. Any existing user accounts on the switch that have been configured for SNMPv3 should be configured only with SHA for authentication and AES/3DES for privacy.

- Disable VRRP.

- Delete all IKE policies that either have MD5 for authentication or DES for encryption. Modify the policies so they use SHA for authentication and 3DES/AES for encryption.

- Delete all SSH Server RSA1 key-pairs.

Enabling FIPS Mode

Detailed Steps

To enable FIPS mode, follow these steps:

Command

Purpose

Step 1

switch# config t

Enters configuration mode.

Step 2

Enables FIPS mode.

Disables FIPS mode.

To enable FIPS mode using DCNM-SAN, follow these steps:

Step 1 Expand Switches from the Physical Attributes pane. Expand Security and then select FIPS.

You see the FIPS activation details in the Information pane as shown in Figure 2-1.

Figure 2-1 FIPS Activation in DCNM-SAN

Step 2 Check the ModeActivation check box next to the switch for which you want to enable FIPS mode.

Step 3 Click Apply Changes to commit and distribute these changes.

Step 4 Click Undo Changes to discard any unsaved changes.

To enable FIPS mode using Device Manager, follow these steps:

Step 1 Choose Physical > System or right-click and select Configure.

You see the System dialog box as shown in Figure 2-2.

Figure 2-2 System Dialog Box

Step 2 Check the FIPSModeActivation check box to enable FIPS mode on the selected switch.

Step 3 Click Apply to save the changes.

Step 4 Click Close to close the dialog box.

Verifying FIPS Configuration

Command

Purpose

Displays the FIPS status.

.

Field Descriptions for FIPS

FIPS

Field

Description

ModeActivation

To enable/disable FIPS mode on the device. FIPS 140-2 is a set of security requirements for cryptographic modules and it details the U.S. Government requirements for cryptographic modules. A module will comprise both hardware and software, eg a datacenter switching or routing module.

The module is said to be in FIPS enabled mode when a request is recieved to enable the FIPS mode and a set of self-tests are successfully run in response to the request. If the self-tests fail, then an appropriate error is returned.

Configuring Users and Common Role

The CLI and SNMP use common roles in all switches in the Cisco MDS 9000 Family. You can use the CLI to modify a role that was created using SNMP and vice versa.

Users, passwords, and roles for all CLI and SNMP users are the same. A user configured through the CLI can access the switch using SNMP (for example, DCNM for SAN (DCNM-SAN or Device Manager) and vice versa.

This chapter includes the following topics:

- Information About Role-Based Authorization

- Guidelines and Limitations

- Default Settings

- Configuring Users and Common Role

- Configuring SSH Services

- Verifying Users and Common Role Configuration

- Field Descriptions for Users and Common Role

- Feature History for Users and Common Role

Information About Role-Based Authorization

Switches in the Cisco MDS 9000 Family perform authentication based on roles. Role-based authorization limits access to switch operations by assigning users to roles. This kind of authentication restricts you to management operations based on the roles to which you have been added.

When you execute a command, perform command completion, or obtain context-sensitive help, the switch software allows the operation to progress if you have permission to access that command.

This section includes the following topics:

- About Roles

- Rules and Features for Each Role

- Rule Changes Between SAN-OS Release 3.3(1c) and NX-OS Release 4.2(1a) Affect Role Behavior

- About the VSAN Policy

- Role Distributions

- About Role Databases

- Locking the Fabric

- About Common Roles

- Mapping of CLI Operations to SNMP

- Creating Users Guidelines

- Characteristics of Strong Passwords

- About SSH

- Boot Mode SSH

- SSH Authentication Using Digital Certificates

- Passwordless File copy and SSH

About Roles

commands.

Note If you belong to multiple roles, you can execute a union of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose you belong to a TechDocs group and you were denied access to configuration commands. However, you also belong to the engineering group and have access to configuration commands. In this case, you will have access to configuration commands.

Tip Any role, when created, does not allow access to the required commands immediately. The administrator must configure appropriate rules for each role to allow access to the required commands.

Rules and Features for Each Role

Up to 16 rules can be configured for each role. These rules reflect what CLI commands are allowed. The user-specified rule number determines the order in which the rules are applied. For example, rule 1 is applied before rule 2, which is applied before rule 3, and so on. A user not belonging to the network-admin role cannot perform commands related to roles.

CLI command if user A does not belong to the network-admin role.

), and an optional feature name (for example, FSPF, zone, VSAN, fcping, or interface).

Note In this case, exec CLI commands refer to all commands in the EXEC mode that are not included in the show, debug, and clear CLI command categories.

Rule Changes Between SAN-OS Release 3.3(1c) and NX-OS Release 4.2(1a) Affect Role Behavior

The rules that can be configured for roles were modified between SAN-OS Release 3.3(1c) and NX-OS Release 4.2(1a). As a result, roles do not behave as expected following an upgrade from SAN-OS Release 3.3(1c) to NX-OS Release 4.2(1a). Manual configuration changes are required to restore the desired behavior.

Rule 4 and Rule 3: after the upgrade, exec and feature are removed. Change rule 4 and rule 3 as follows:

SAN-OS Release 3.3(1c) Rule

NX-OS Release 4.2(1a), Set the Rule to:

rule 4 permit exec feature debug

rule 4 permit debug

rule 3 permit exec feature clear

rule 3 permit clear

Rule 2: after the upgrade, exec feature license is obsolete.

SAN-OS Release 3.3(1c) Rule

NX-OS Release 4.2(1a) Rule

rule 2 permit exec feature debug

Not available in Release 4.2(1).

Rule 9, Rule 8, and Rule 7: after the upgrade, you need to have the feature enabled to configure it. In SAN-OS Release 3.3(1c), you could configure a feature without enabling it.

SAN-OS Release 3.3(1c) Rule

NX-OS Release 4.2(1a), to Preserve the Rule:

rule 9 deny config feature telnet

Not available in Release 4.2(1) and cannot be used.

rule 8 deny config feature tacacs-server

During the upgrade, enable the feature to preserve the rule; otherwise, the rule disappears.

rule 7 deny config feature tacacs+

During the upgrade, enable the feature to preserve the rule; otherwise, the rule disappears.

About the VSAN Policy

Configuring the VSAN policy requires the ENTERPRISE_PKG license (For more information, see Cisco MDS 9000 Family NX-OS Licensing Guide).

You can configure a role so that it only allows tasks to be performed for a selected set of VSANs. By default, the VSAN policy for any role is permit, which allows tasks to be performed for all VSANs. You can configure a role that only allows tasks to be performed for a selected set of VSANs. To selectively allow VSANs for a role, set the VSAN policy to deny, and then set the configuration to permit or the appropriate VSANs.

Note Users configured in roles where the VSAN policy is set to deny cannot modify the configuration for E ports. They can only modify the configuration for F or FL ports (depending on whether the configured rules allow such configuration to be made). This is to prevent such users from modifying configurations that may impact the core topology of the fabric.

Tip Roles can be used to create VSAN administrators. Depending on the configured rules, these VSAN administrators can configure MDS features (for example, zone, fcdomain, or VSAN properties) for their VSANs without affecting other VSANs. Also, if the role permits operations in multiple VSANs, then the VSAN administrators can change VSAN membership of F or FL ports among these VSANs.

Users belonging to roles in which the VSAN policy is set to deny are referred to as VSAN-restricted users.

Role Distributions

Role-based configurations use the Cisco Fabric Services (CFS) infrastructure to enable efficient database management, and to provide a single point of configuration for the entire fabric.

The following configurations are distributed:

- Role names and descriptions

- List of rules for the roles

- VSAN policy and the list of permitted VSANs

About Role Databases

Role-based configurations use two databases to accept and implement configurations.

- Configuration database—The running database currently enforced by the fabric.

- Pending database—Your subsequent configuration changes are stored in the pending database. If you modify the configuration, you need to commit or discard the pending database changes to the configuration database. The fabric remains locked during this period. Changes to the pending database are not reflected in the configuration database until you commit the changes.

Locking the Fabric

The first action that modifies the database creates the pending database and locks the feature in the entire fabric. 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 change.

About Common Roles

The CLI and SNMP in all switches in the Cisco MDS 9000 Family use common roles. You can use SNMP to modify a role that was created using the CLI and vice versa (see Figure 3-1).

Figure 3-1 Common Roles

Each role in SNMP is the same as a role created or modified through the CLI (see the “Information About Role-Based Authorization” section).

Each role can be restricted to one or more VSANs as required.

You can create new roles or modify existing roles using SNMP or the CLI.

- SNMP—Use the CISCO-COMMON-ROLES-MIB to configure or modify roles. Refer to the Cisco MDS 9000 Family MIB Quick Reference .

- CLI—Use the role name command.

Mapping of CLI Operations to SNMP

SNMP has only three possible operations: GET, SET, and NOTIFY. The CLI has five possible operations: DEBUG, SHOW, CONFIG, CLEAR, and EXEC.

Note NOTIFY does not have any restrictions like the syslog messages in the CLI.

explains how the CLI operations are mapped to the SNMP operations.

Table 3-1 CLI Operation to SNMP Operation Mapping

CLI Operation

SNMP Operation

DEBUG

Ignored

SHOW

GET

CONFIG

SET

CLEAR

SET

EXEC

SET

Creating Users Guidelines

option are synchronized.

option determines the date on which the user account is disabled. The date is specified in the YYYY-MM-DD format.

When creating users, note the following guidelines:

- You can configure up to a maximum of 256 users on a switch.

- 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.

- User passwords are not displayed in the switch configuration file.

- If a password is trivial (short, easy-to-decipher), your password configuration is rejected. Be sure to configure a strong password as shown in the sample configuration. Passwords are case-sensitive. “admin” is no longer the default password for any Cisco MDS 9000 Family switch. You must explicitly configure a strong password.

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

Caution Cisco MDS NX-OS supports user names that are created with alphanumeric characters or specific special characters (+ [plus], = [equal], _ [underscore], - [hyphen], \ [backslash], and . [period]) whether created remotely (using TACACS+ or RADIUS) or locally. Local user names cannot be created with any special characters (apart from those specified). If a non-supported special character user name exists on an AAA server, and is entered during login, then the user is denied access.

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 upper- and lower-case characters

- Contains numbers

The following are examples of strong passwords:

- If2CoM18

- 2004AsdfLkj30

- Cb1955S21

About SSH

SSH provides secure communications to the Cisco NX-OS CLI. You can use SSH keys for the following SSH options:

- SSH2 using RSA

- SSH2 using DSA

Boot Mode SSH

Due to the increasing emphasis on security and security-related issues, the ssh command in this release runs in the Boot mode. SSH is a preferred and more secure method of data exchange over the network because it communicates over the secure channel, and the data is encrypted before sending on the channel.

Example 3-1 shows how to use the ssh command to conncet to a remote server from any switch.

Example 3-1 Connecting a Remote Server from Any Switch

switch# ssh admin @ hostname

SSH Authentication Using Digital Certificates

SSH authentication on the Cisco MDS 9000 Family switches provide X.509 digital certificate support for host authentication. An X.509 digital certificate is a data item that vouches for the origin and integrity of a message. It contains encryption keys for secured communications and is “signed” by a trusted certification authority (CA) to verify the identity of the presenter. The X.509 digital certificate support provides either DSA or RSA algorithms for authentication.

The certificate infrastructure uses the first certificate that supports the Secure Socket Layer (SSL) and is returned by the security infrastructure, either through query or notification. Verification of certificates is successful if the certificates are from any of the trusted CAs.

You can configure your switch for either SSH authentication using an X.509 certificate or SSH authentication using a Public Key Certificate, but not both. If either of them is configured and the authentication fails, you will be prompted for a password.

For more information on CAs and digital certificates, see Chapter6, “Configuring Certificate Authorities and Digital Certificates”

Passwordless File copy and SSH

Secure Shell (SSH) public key authentication can be used to achieve password-free logins. SCP and SFTP uses SSH in the background, which enables these copy protocols to be used for a password-free copy with public key authentication. The NX-OS version only supports the SCP and STFP client functionality.

You can create an RSA and DSA identity that can be used for authentication with SSH. The identity consists of two parts: public and private keys. The public and the private keys are generated by the switch or can be generated externally and imported to the switch. For import purposes, the keys should be in OPENSSH format.

To use the key on a host machine hosting an SSH server, you must transfer the public key file to the machine and add the contents of it to the authorized_keys file in your SSH directory (for example, $HOME/.ssh) on the server. For the import and export of private keys, the key is protected by encryption. You are asked to enter the passphrase for the keys. If you enter a passphrase, the private key is protected by encryption. If you leave the password field blank, the key will not be encrypted.

If you need to copy the keys to another switch, you will have to export the keys out of the switch to a host machine, and then import the keys to other switches from that machine.

The key files are persistent across reload.

Guidelines and Limitations

Fabric merge does not modify the role database on a switch. If two fabrics merge, and the fabrics have different role databases, the software generates an alert message.

See the “Merge Guidelines for RADIUS and TACACS+ Configurations” section for detailed concepts.

- Verify that the role database is identical on all switches in the entire fabric.

- Be sure to edit the role database on any switch to the desired database and then commit it. This synchronizes the role databases on all the switches in the fabric.

Default Settings

lists the default settings for all switch security features in any switch.

Table 3-2 Default Switch Security Settings

Parameters

Default

Roles in Cisco MDS Switches

Network operator (network-operator)

AAA configuration services

Local

Authentication port

1812

Accounting port

1813

Preshared key communication

Clear text

RADIUS server time out

1 (one) second

RADIUS server retries

Once

TACACS+

Disabled

TACACS+ servers

None configured

TACACS+ server timeout

5 seconds

AAA server distribution

Disabled

VSAN policy for roles

Permit

User account

No expiry (unless configured)

Password

None

Password-strength

Enabled

Accounting log size

250 KB

SSH service

Enabled

Telnet service

Disabled

Configuring Users and Common Role

This section includes the following topics:

- Configuring Roles and Profiles

- Deleting Common Roles

- Modifying Profiles

- Modifying Rules

- Modifying the VSAN Policy

- Committing Role-Based Configuration Changes

- Discarding Role-Based Configuration Changes

- Enabling Role-Based Configuration Distribution

- Clearing Sessions

- Checking Password Strength

- Configuring Users

- Logging Out Users

- Deleting a User

Configuring Roles and Profiles

Detailed Steps

To create an additional role or to modify the profile for an existing role, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-role)#

Places you in the mode for the specified role (techdocs).

Note The role submode prompt indicates that you are now in the role submode. This submode is now specific to the techdocs group.

Deletes the role called techdocs.

Step 3

Assigns a description to the new role. The description is limited to one line and can contain spaces.

Resets the description for the Tech Docs group.

Note Only users belonging to the network-admin role can create roles.

To create an additional role or to modify the profile for an existing role using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles from the Physical Attributes pane.

Step 2 Click the Roles tab in the Information pane.

Step 3 Click Create Row to create a role in DCNM-SAN.

Step 4 Select the switches on which to configure a role.

Step 5 Enter the name of the role in the Name field.

Step 6 Enter the description of the role in the Description field.

Step 7 (Optional) Check the Enable check box to enable the VSAN scope and enter the list of VSANs in the Scope field to which you want to restrict this role.

Step 8 Click Create to create the role.

Note Device Manager automatically creates six roles that are required for Device Manager to display a view of a switch. These roles are system, snmp, module, interface, hardware, and environment.

Deleting Common Roles

Detailed Steps

To delete a common role using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles from the Physical Attributes pane.

Step 2 Click the Roles tab in the Information pane.

Step 3 Click the role you want to delete.

Step 4 Click Delete Row to delete the common role.

to cancel it.

Modifying Profiles

Detailed Steps

To modify the profile for an existing role, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-role)#

Places you in role configuration submode for the existing role sangroup.

Step 3

EXEC mode command.

Step 4

command.

configuration commands.

Modifying Rules

Detailed Steps

To modify the rules for an existing role using Device Manager, follow these steps:

Step 1 Choose Security > Roles.

Step 2 Click the role for which you want to edit the rules.

Step 3 Click Rules to view the rules for the role.

You see the Edit Role Rules dialog box.

Step 4 Edit the rules you want to enable or disable for the common role.

Step 5 Click Apply to apply the new rules.

CLI configuration commands.

Note The order of rule placement is important. If you had swapped these two rules and issued the deny config feature fspf rule first and issued the permit config rule next, you would be allowing all sangroup users to perform all configuration commands because the second rule globally overrode the first rule.

Modifying the VSAN Policy

Detailed Steps

To modify the VSAN policy for an existing role, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-role)#

Places you in role configuration submode for the sangroup role.

Step 3

switch(config-role-vsan)

and places you in a submode where VSANs can be selectively permitted.

).

Step 4

Permits this role to perform the allowed commands for VSANs 10 through 30.

Removes the permission for this role to perform commands for VSANs 15 to 20. So, the role is now permitted to perform commands for VSAN 10 to 14, and 21 to 30.

To modify the VSAN policy for an existing role using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles from the Physical Attributes pane.

Step 2 Click the Roles tab in the Information pane.

Enable check box if you want to enable the VSAN scope and restrict this role to a subset of VSANs.

Step 4 Enter the list of VSANs in the Scope VSAN Id List field that you want to restrict this role to.

Step 5 Click Apply Changes to save these changes.

Committing Role-Based Configuration Changes

If you commit the changes made to the pending 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. The configuration database now contains the committed changes and the pending database is now cleared.

Detailed Steps

To commit role-based configuration changes, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Commits the role-based configuration changes.

To commit role-based configuration changes using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles in the Physical Attributes pane.

Step 2 Click the Roles CFS tab in the Information pane.

Step 3 Set the Global drop-down menu to enable to enable CFS.

Step 4 Click the Apply Changes icon to save this change.

Step 5 Set the Config Action drop-down menu to commit to commit the roles using CFS.

Step 6 Click the Apply Changes icon to save this change.

Discarding Role-Based Configuration Changes

If you discard (abort) the changes made to the pending database, the configuration database remains unaffected and the lock is released.

Detailed Steps

To discard role-based configuration changes, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Discards the role-based configuration changes and clears the pending configuration database.

To discard role-based configuration changes using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles in the Physical Attributes pane.

tab in the Information pane.

Step 3 Set the Config Action drop-down menu to abort to discard any uncommitted changes.

Step 4 Click the Apply Changes icon to save this change.

Enabling Role-Based Configuration Distribution

Detailed Steps

To enable role-based configuration distribution, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Enables role-based configuration distribution.

Disables role-based configuration distribution (default).

To enable role-based configuration distribution using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles in the Physical Attributes pane.

tab in the Information pane.

Step 3 Set the Global drop-down menu to enable to enable CFS distribution.

Step 4 Click the Apply Changes icon to save this change.

Clearing Sessions

Detailed Steps

command from any switch that is part of the initiated session.

switch# clear role session

To forcibly clear the existing role session in the fabric using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles in the Physical Attributes pane.

tab in the Information pane.

Step 3 Set the Config Action drop-down menu to clear to clear the pending database.

Step 4 Click the Apply Changes icon to save this change.

Caution Any changes in the pending database are lost when you clear a session.

Checking Password Strength

You can check the strength of the configured password.

When you enable password checking, the NX-OS software allows you to create strong passwords only.

Detailed Steps

To enable password strength checking, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables (default) password checking.

Step 3

Disables password checking.

Configuring Users

Before configuring users, make sure that you have configured roles to associate with the users that you are creating.

Note As of Cisco SAN-OS Release 3.1(2b), DCNM-SAN automatically checks whether encryption is enabled, which allows you to create users.

Detailed Steps

To configure a new user or to modify the profile of an existing user, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Creates or updates the user account (usam) along with a password (abcd123AAA) that is set to expire on 2003-05-31. The password is limited to 64 characters.

Note User account names must contain non-numeric characters.

Creates or updates the user account (msam) along with a password (abcd12AAA) specified in clear text (indicated by 0). The password is limited to 64 characters.

Note User account names must contain non-numeric characters.

Specifies an encrypted (specified by 5) password (!@*asdsfsdfjh!@df) for the user account (user1).

Step 3

Adds the specified user (usam) to the network-admin role.

Deletes the specified user (usam) from the vsan-admin role.

Step 4

Specifies the SSH key for an existing user account (admin).

Deletes the SSH key for the user account (admin).

Step 5

Specifies an SSH X.509 certificate distinguished name and DSA algorithm to use for authentication for an existing user account (usam).

Specifies an SSH X.509 certificate distinguished name and RSA algorithm to use for authentication for an existing user account (user1).

Removes the SSH X.509 certificate distinguished name for the user account (admin).

To configure a new user or to modify the profile of an existing user using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles from the Physical Attributes pane.

Step 2 Click the Users tab in the Information pane to see a list of users.

Step 3 Click the Create Row icon.

You see the Users - Create dialog box as shown in Figure 3-2.

Figure 3-2 Users - Create Dialog Box

Step 4 (Optional) Alter the Switches check boxes to specify one or more switches.

Step 5 Enter the user name in the New User field.

Step 6 Enter the password for the user.

Step 7 Check the roles that you want to associate with this user.

See the “Rules and Features for Each Role” section.

Step 8 Select the appropriate option for the type of authentication protocol used. The default value is MD5.

Step 9 Select the appropriate option for the type of privacy protocol used. The default value is DES.

Step 10 (Optional) Enter the expiry date for this user.

Step 11 (Optional) Enter the SSH Key filename.

Step 12 Click Create to create the entry.

Logging Out Users

Detailed Steps

command.

In the following example, the user named vsam is logged out from the switch:

switch# clear user vsam

command to view a list of the logged in users (see Example 3-2).

Example 3-2 Displays All Logged in Users

switch# show users

admin pts/7 Jan 12 20:56 (10.77.202.149)

admin pts/9 Jan 12 23:29 (user.example.com)

admin pts/10 Jan 13 03:05 (dhcp-10-10-1-1.example.com)

admin pts/11 Jan 13 01:53 (dhcp-10-10-2-2.example.com)

Deleting a User

Detailed Steps

To delete a user using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles from the Physical Attributes pane.

Step 2 Click the Users tab in the Information pane to see a list of users.

Step 3 Click the name of the user you want to delete.

Step 4 Click Delete Row to delete the selected user.

Step 5 Click Apply Changes to save this change.

Configuring SSH Services

A secure SSH connection with an RSA key is available as a default on all Cisco MDS 9000 Family switches. If you require a secure SSH connection with a DSA key, you need to disable the default SSH connection, Generate a DSA key and then enable the SSH connection (see the “Generating the SSH Server Key Pair” section).

command to generate a server key.

Caution If you are logging in to a switch through SSH and you have issued the aaa authentication login default none command, you must enter one or more key strokes to log in. If you press the Enter key without entering at least one keystroke, your log in will be rejected.

This section includes the following topics:

- Generating the SSH Server Key Pair

- Specifying the SSH Key

- Overwriting a Generated Key Pair

- Enabling SSH or Telnet Service

- Generating SSH User Key Pairs

- Changing Administrator Password Using DCNM-SAN

- Recovering the Administrator Password

Generating the SSH Server Key Pair

Ensure that you have an SSH server key pair with the appropriate version before enabling the SSH service. Generate the SSH server key pair according to the SSH client version used. The number of bits specified for each key pair ranges from 768 to 2048.

The SSH service accepts two types of key pairs for use by SSH version 2.

- The dsa option generates the DSA key pair for the SSH version 2 protocol.

- The rsa option generates the RSA keypair for the SSH version 2 protocol.

Caution If you delete all of the SSH keys, you cannot start a new SSH session.

Detailed Steps

To generate the SSH server key pair, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

generating dsa key.....

generated dsa key

Generates the DSA server key pair.

generating rsa key.....

generated rsa key

Generates the RSA server key pair.

cleared RSA keys

Clears the RSA server key pair configuration.

To generate the SSH key pair using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select SSH and Telnet.

Step 2 Click the Create Row icon.

You see the SSH and Telnet Key - Create dialog box (see Figure 3-3).

Figure 3-3 SSH and Telnet - Create Dialog Box

Step 3 Check the switches you want to assign to this SSH key pair.

Step 4 Choose the key pair option type from the listed Protocols. The listed protocols are SSH1, SSH2(rsa), and SSH2(dsa).

Step 5 Set the number of bits that will be used to generate the key pairs in the NumBits drop-down menu.

Step 6 Click Create to generate these keys.

Note 1856 DSA NumberKeys are not supported by switches that running Cisco MDS NX-OS software version 4.1(1) and later.

Specifying the SSH Key

You can specify an SSH key to log in using the SSH client without being prompted for a password. You can specify the SSH key in three different formats:

- Open SSH format

- IETF SECSH format

- Public Key Certificate in PEM format

Detailed Steps

To specify or delete the SSH key in OpenSSH format for a specified user, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Specifies the SSH key for the user account (admin).

Deletes the SSH key for the user account (admin).

To specify or delete the SSH key in IETF SECSH format for a specified user, follow these steps:

Command

Purpose

Step 1

Downloads the file containing the SSH key in IETF SECSH format.

Step 2

switch(config)#

Enters configuration mode.

Step 3

Specifies the SSH key for the user account (admin).

Deletes the SSH key for the user account (admin).

To specify or delete the SSH key in PEM-formatted Public Key Certificate form for a specified user, follow these steps:

Command

Purpose

Step 1

Downloads the file containing the SSH key in PEM-formatted Public Key Certificate form.

Step 2

switch(config)#

Enters configuration mode.

Step 3

Specifies the SSH key for the user account (usam).

Deletes the SSH key for the user account (usam).

Overwriting a Generated Key Pair

If the SSH key pair option is already generated for the required version, you can force the switch to overwrite the previously generated key pair.

Detailed Steps

To overwrite the previously generated key pair, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

ssh key dsa 512

dsa keys already present, use force option to overwrite them

deleting old dsa key.....

generating dsa key.....

generated dsa key

option to overwrite that server key pair.

Deletes the old DSA key and sets the server key pair using the new bit specification.

To overwrite the previously generated key pair using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select SSH and Telnet.

You see the configuration in the Information pane.

Step 2 Highlight the key that you want to overwrite and click Delete Row.

Step 3 Click the Apply Changes icon to save these changes.

Step 4 Click the Create Row icon.

You see the SSH and Telnet Key - Create dialog box.

Step 5 Check the switches you want to assign this SSH key pair.

Step 6 Choose the key pair option type from the Protocols radio buttons.

Step 7 Set the number of bits that will be used to generate the key pairs in the NumBits drop-down menu.

Step 8 Click Create to generate these keys.

Enabling SSH or Telnet Service

By default, the SSH service is enabled with the RSA key.

Detailed Steps

To enable or disable the SSH or Telnet service, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

updated

Enables the use of the SSH service.

updated

Disables (default) the use of the SSH service.

updated

Enables the use of the Telnet service.

updated

Disables (default) the use of the Telnet service.

Note If you are logging in to a switch through SSH and you have issued the aaa authentication login default none CLI command, you must enter one or more key strokes to log in. If you press the Enter key without entering at least one keystroke, your log in will be rejected.

DCNM-SAN enables SSH automatically when you configure it.

To enable or disable SSH using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select SSH and Telnet.

check box for each switch (see Figure 3-4).

Figure 3-4 Control Tab under SSH and Telnet

Step 3 Click the Apply Changes icon to save this change.

Generating SSH User Key Pairs

Detailed Steps

To import and export the key pair, the following CLIs are provided. The CLI command to generate the ssh user key pairs on the switch is defined as follows:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

generating rsa key(1024 bits).....

generated rsa key

Generates public and private RSA keys for the account (admin). It then stores the key files in the home directory of the specified user. Use the force option to overwrite that server keypair.

Note This example is for RSA keys. Replace rsa with dsa for DSA keys.

Deletes the public and private RSA keys for the account (admin).

Step 3

**************************************

rsa Keys generated: Thu Jul 9 11:10:29 2009

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxWmjJT+oQhIcvnrMbx2BmD0P8boZElTfJFx9fexWp6rOiztlwODtehnjadWc6A+DE2DvYNvqsrU9TBypYDPQkR/+Y6cKubyFWVxSBG/NHztQc3+QC1zdkIxGNJbEHyFoajzNEO8LLOVFIMCZ2Td7gxUGRZc+fbqS33GZsCAX6v0=

bitcount:262144

fingerprint:

8d:44:ee:6c:ca:0b:44:95:36:d0:7d:f2:b5:78:74:7d

**************************************

could not retrieve dsa key information

**************************************

Shows the public key for the account (admin).

Step 4

Enter Passphrase:

switch(config)# dir

951 Jul 09 11:13:59 2009 key_rsa

221 Jul 09 11:14:00 2009 key_rsa.pub

Exports the keypair from the user’s (admin’s) home directory to the bootflash memory.

The key pair (both public and private keys) will be exported to the specified location. The user will be prompted to enter a Passphrase which will encrypt the private key. The private key will be exported as the file name specified in the uri and the public key will be exported with the same file name followed by a “.pub” extension.

The user can now copy this key pair to any switch, and also copy the public file to the home directory of the SCP server.

Step 5

Enter Passphrase:

switch(config)# show username admin keypair

**************************************

rsa Keys generated: Thu Jul 9 11:10:29 2009

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAxWmjJT+oQhIcvnrMbx2BmD0P8boZElTfJFx9fexWp6rOiztlwODtehnjadWc6A+DE2DvYNvqsrU9TBypYDPQkR/+Y6cKubyFWVxSBG/NHztQc3+QC1zdkIxGNJbEHyFoajzNEO8LLOVFIMCZ2Td7gxUGRZc+fbqS33GZsCAX6v0=

bitcount:262144

fingerprint:

8d:44:ee:6c:ca:0b:44:95:36:d0:7d:f2:b5:78:74:7d

**************************************

could not retrieve dsa key information

**************************************

Imports the keypair to the home directory of the switch.

The uri given here must be the uri of the private key and the public should be present on the same location with extension “.pub”. The user will be prompted for the passphrase, and the same passphrase must be entered as was used to encrypt the key.

Once the private keys are copied to the switches which need to do passwordless copy to a server, and that server has the public key copied to its authorized_keys file in home directory, the user will be able to do passwordless file copy and ssh to the server from the switches.

Note To copy the public key to the authorized_keys file on the server, user can also copy the key from the show command mentioned above.

Step 6

server# cat key_rsa.pub >> $HOME/.ssh/ authorized_keys

Appends the public key stored in key_rsa.pub to the authorized_keys file on the SCP server. The passwordless ssh/scp is then enabled from the switch to this server using the standard ssh and scp commands.

Changing Administrator Password Using DCNM-SAN

Detailed Steps

To change the administrator password in DCNM-SAN, follow these steps:

Step 1 Click the Open tab in the control panel.

Step 2 Choose the password field to change the password for an already existing user for the fabric.

Step 3 Click Open to open the fabric.

Note New password will be saved after the fabric is open. The user name and password fields are editable in the Fabric tab only after you unmanage the fabric.

Recovering the Administrator Password

You can recover the administrator password using one of two methods:

- From the CLI with a user name that has network-admin privileges.

- Power cycling the switch.

Note To recover an administrator’s password, refer to the Cisco MDS 9000 Family NX-OS Security Configuration Guide.

The following topics included in this section:

- Using the CLI with Network-Admin Privileges

- Power Cycling the Switch

Using the CLI with Network-Admin Privileges

Detailed Steps

If you are logged in to, or can log into, switch with a user name that has network-admin privileges and then recover the administrator password, follow these steps:

command to verify that your user name 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

command to assign a new administrator password.

switch# config t

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 3 Save the software 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 administrator password by power cycling the switch.

Caution This procedure disrupts all traffic on the switch. All connections to the switch will be lost for 2 to 3 minutes.

Note You cannot recover the administrator password from a Telnet or SSH session. You must have access to the local console connection.

Detailed Steps

To recover a administrator password by power cycling the switch, follow these steps:

slot 6 from the chassis.

Note On the Cisco MDS 9500 Series, the password recovery procedure must be performed on the active supervisor module. Removing the supervisor module in slot 6 ensures that a switchover will not occur during the password recovery procedure.

Step 2 Power cycle the switch.

prompt mode.

Ctrl-]

switch(boot)#

Step 4 Change to configuration mode.

switch(boot)# config terminal

Step 5 Issue the admin-password command to reset the administrator password. This will disable remote authentication for login through console, if enabled. This is done to ensure that admin is able to login through console with new password after password recovery. Telnet/SSH authentication will not be affected by this.

switch(boot-config)# admin-password <new password>

WARNING! Remote Authentication for login through console will be disabled#

For information on strong passwords, see the “Checking Password Strength” section.

Step 6 Exit to the EXEC mode.

switch(boot-config)# admin-password <new password>

command to load the Cisco NX-OS software.

switch(boot)# load bootflash:m9500-sf1ek9-mz.2.1.1a.bin

Caution If you boot a system image that is older than the image you used to store the configuration and do not use the install all command to boot the system, the switch erases the binary configuration and uses the ASCII configuration. When this occurs, you must use the init system command to recover your password.

Step 8 Log in to the switch using the new administrator password.

switch login: admin

Password: <new password>

Step 9 Reset the new password to ensure that is it is also the SNMP password for DCNM-SAN.

switch# config t

switch(config)# username admin password <new password>

switch(config)# exit

switch#

Step 10 Save the software configuration.

switch# copy running-config startup-config

Step 11 Insert the previously removed supervisor module into slot 6 in the chassis.

Verifying Users and Common Role Configuration

To display Monitoring Users and Common Role configuration information, perform one of the following tasks:

Command

Purpose

Displays information for all roles.

Displays the Role Status Information.

show role pending

Displays Information on the Pending Roles Database.

show role pending-diff

Displays the Differences Between the Two Databases.

show role name my_role

Displays CLI Operation to SNMP Operation Mapping.

show user-account user1

Displays Information for a Specified User.

show user-account

Displays Information for All Users.

show ssh server

Displays SSH Protocol Status.

show ssh key

Displays Server Key-Pair Details.

.

This section includes the following topics:

- Displaying Role-Based Information

- Displaying Role-Based Information

- Displaying Roles When Distribution is Enabled

- Displaying User Account Information

- Displaying SSH Protocol Status

Displaying Role-Based Information

The rules are displayed by rule number and are based on each role. All roles are displayed if the role name is not specified.

To view rules for a role using Device Manager, follow these steps:

Step 1 Click Security > Roles.

You see the Roles dialog box.

Step 2 Select a role name and click Rules.

You see the Rules dialog box.

to get a summarized view of the rules configured for this role.

Displaying Role-Based Information

command to display rules configured on the switch. The rules are displayed by rule number and are based on each role. All roles are displayed if the role name is not specified. See Example 3-3.

Example 3-3 Displays Information for All Roles

switch# show role

Role: network-admin

Description: Predefined Network Admin group. This role cannot be modified

Access to all the switch commands

Role: network-operator

Description: Predefined Network Operator group. This role cannot be modified

Access to Show commands and selected Exec commands

Role: svc-admin

Description: Predefined SVC Admin group. This role cannot be modified

Access to all SAN Volume Controller commands

Role: svc-operator

Description: Predefined SVC Operator group. This role cannot be modified

Access to selected SAN Volume Controller commands

Role: TechDocs

vsan policy: permit (default)

Role: sangroup

Description: SAN management group

vsan policy: deny

Permitted vsans: 10-30

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

Rule Type Command-type Feature

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

1. permit config *

2. deny config fspf

3. permit debug zone

4. permit exec fcping

Displaying Roles When Distribution is Enabled

command to display the configuration database.

command to display whether distribution is enabled for role configuration, the current fabric status (locked or unlocked), and the last operation performed. See Example 3-4.

Example 3-4 Displays the Role Status Information

switch# show role status

Distribution: Enabled

Session State: Locked

Last operation (initiated from this switch): Distribution enable

Last operation status: Success

command to display the pending role database.

command by following this procedure:

command.

command.

command to see the output.

Example 3-5 Displays Information on the Pending Roles Database

switch# show role pending

Role: network-admin

Description: Predefined Network Admin group. This role cannot be modified

Access to all the switch commands

Role: network-operator

Description: Predefined Network Operator group. This role cannot be modified

Access to Show commands and selected Exec commands

Role: svc-admin

Description: Predefined SVC Admin group. This role cannot be modified

Access to all SAN Volume Controller commands

Role: svc-operator

Description: Predefined SVC Operator group. This role cannot be modified

Access to selected SAN Volume Controller commands

Role: TechDocs

vsan policy: permit (default)

Role: sangroup

Description: SAN management group

vsan policy: deny

Permitted vsans: 10-30

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

Rule Type Command-type Feature

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

1. permit config *

2. deny config fspf

3. permit debug zone

4. permit exec fcping

Role: myrole

vsan policy: permit (default)

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

Rule Type Command-type Feature

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

1. permit config fspf

command to display the differences between the pending and configuration role database. See Example 3-6.

Example 3-6 Displays the Differences Between the Two Databases

switch# show role pending-diff

+Role: myrole

+ vsan policy: permit (default)

+ ---------------------------------------------

+ Rule Type Command-type Feature

+ ---------------------------------------------

+ 1. permit config fspf

To view the roles using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security and then select Users and Roles in the Physical Attributes pane.

Step 2 Click the Users tab in the Information pane (see Figure 3-5).

Figure 3-5 Roles CFS Tab

Step 3 Set the Config View As drop-down value to pending to view the pending database or set the Config View as drop-down menu to running to view the running database.

Step 4 Click Apply Changes to save this change.

Example 3-7 shows the privileges and rules mapping CLI operations to SNMP operations for a role named my_role.

Example 3-7 Displays CLI Operation to SNMP Operation Mapping

switch# show role name my_role

Role:my_role

vsan policy:permit (default)

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

Rule Type Command-type Feature

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

1. permit clear *

2. deny clear ntp

3. permit config *

4. deny config ntp

5. permit debug *

6. deny debug ntp

7. permit show *

8. deny show ntp

9. permit exec *

Note Although CONFIG is denied for NTP in rule 4, rule 9 allows the SET to NTP MIB objects because EXEC also maps to the SNMP SET operation

Displaying User Account Information

.

Example 3-8 Displays Information for a Specified User

switch# show user-account user1

user:user1

this user account has no expiry date

roles:network-operator

no password set. Local login not allowed

Remote login through RADIUS is possible

Example 3-9 Displays Information for All Users

switch# show user-account

show user-account

user:admin

this user account has no expiry date

roles:network-admin

user:usam

expires on Sat May 31 00:00:00 2003

roles:network-admin network-operator

user:msam

this user account has no expiry date

roles:network-operator

user:user1

this user account has no expiry date

roles:network-operator

no password set. local login not allowed

Remote login through RADIUS is possible

To display information about configured user accounts using DCNM-SAN, follow these steps:

Step 1 Expand Security and then select Users and Roles in the Physical Attributes pane.

Step 2 Click the Users tab.

You see the list of SNMP users shown in Figure 3-6 in the Information pane.

Figure 3-6 Users Listed Under the Users Tab

Displaying SSH Protocol Status

command to display the status of the SSH protocol (enabled or disabled) and the versions that are enabled for that switch (see Example 3-10).

Example 3-10 Displays SSH Protocol Status

switch# show ssh server

ssh is enabled

version 1 enabled

version 2 enabled

command to display the server key-pair details for the specified key or for all keys, (see Example 3-11).

Example 3-11 Displays Server Key-Pair Details

switch# show ssh key

rsa1 Keys generated:Sun Jan 13 07:16:26 1980

1024 35

fingerprint:

1024 67:76:02:bd:3e:8d:f5:ad:59:5a:1e:c4:5e:44:03:07

could not retrieve rsa key information

dsa Keys generated:Sun Jan 13 07:40:08 1980

ssh-dss AAAAB3NzaC1kc3MAAABBAJTCRQOydNRel2v7uiO6Fix+OTn8eGdnnDVxw5eJs5OcOEXOyjaWcMMYsEgxc9ada1NElp8Wy7GPMWGOQYj9CU0AAAAVAMCcWhNN18zFNOIPo7cU3t7d0iEbAAAAQBdQ8UAOi/Cti84qFb3kTqXlS9mEhdQUo0lHcH5bw5PKfj2Y/dLR437zCBKXetPj4p7mhQ6Fq5os8RZtJEyOsNsAAABAA0oxZbPyWeR5NHATXiyXdPI7j9i8fgyn9FNipMkOF2Mn75Mi/lqQ4NIq0gQNvQOx27uCeQlRts/QwI4q68/eaw=

fingerprint:

512 f7:cc:90:3d:f5:8a:a9:ca:48:76:9f:f8:6e:71:d4:ae

Note If you are logging in to a switch through SSH and you have issued the aaa authentication login default none CLI command, you must enter one or more key strokes to log in. If you press the Enter key without entering at least one keystroke, your log in will be rejected.

Field Descriptions for Users and Common Role

Common Roles

Note Common roles is not available in displayFCoE mode (use security roles).

Field

Description

Description

Description of the common role.

Enable

This specifies whether the common role has a VSAN restriction or not.

List

List of VSANs user is restricted to.

Feature History for Users and Common Role

lists the release history for this feature. Only features that were introduced or modified in 5.x or a later release appear in the table.

Remove the second sentence, above, if it does not apply to the table.

Table 3-3 Feature History for FIPS

Feature Name

Releases

Feature Information

Changes to SSH

5.0(1a)

Boot Mode SSH, Passwordfree File copy, and SSH.

Role Distributions

5.0(1a)

Enabling role-based configuration distribution.

Creating Users Guidelines

5.0(1a)

Caution has been changed.

Configuring Security Features on an External AAA Server

The authentication, authorization, and accounting (AAA) feature verifies the identity of, grants access to, and tracks the actions of users managing a switch. All Cisco MDS 9000 Family switches use Remote Access Dial-In User Service (RADIUS) or Terminal Access Controller Access Control device Plus (TACACS+) protocols to provide solutions using remote AAA servers.

Based on the user ID and password combination provided, switches perform local authentication or authorization using the local database or remote authentication or authorization using a AAA server. A preshared secret key provides security for communication between the switch and AAA servers. This secret key can be configured for all AAA servers or for only a specific AAA server. This security feature provides a central management capability for AAA servers.

This chapter includes the following topics:

- Information About Switch Management Security

- Guidelines and Limitations

- Default Settings

- Configuring the RADIUS, TACACS+, and LDAP Server

- Verifying RADIUS and TACACS+ Configuration

- Feature History for RADIUS, TACACS+, and LDAP

- Monitoring RADIUS and TACACS+

Information About Switch Management Security

Management security in any switch in the Cisco MDS 9000 Family provides security to all management access methods, including the command-line interface (CLI) or Simple Network Management Protocol (SNMP).

This section includes the following topics:

- Security Options

- SNMP Security Options

- Switch AAA Functionalities

- LDAP

- LDAP Authentication and Authorization

- About RADIUS Server Default Configuration

- About the Default RADIUS Server Encryption Type and Preshared Key

- About RADIUS Servers

- About Validating a RADIUS Server

- About Vendor-Specific Attributes

- VSA Format

- Specifying SNMPv3 on AAA Servers

- One-Time Password Support

- About TACACS+

- About TACACS+ Server Default Configuration

- About the Default TACACS+ Server Encryption Type and Preshared Key

- About TACACS+ Servers

- Password Aging Notification through TACACS+ Server

- About Validating a TACACS+ Server

- About Users Specifying a TACACS+ Server at Login

- About Bypassing a Nonresponsive Server

- AAA Server Distribution

- Starting a Distribution Session on a Switch

- CHAP Authentication

- MSCHAP Authentication

- About Enabling MSCHAP

- Local AAA Services

- Accounting Services

Security Options

You can access the CLI using the console (serial connection), Telnet, or Secure Shell (SSH). You can access DCNM-SAN using TCP/UDP SNMP or HTTP traffic. For each management path (console, Telnet, and SSH), you can configure one or more of the following security control options: local, remote (RADIUS or TACACS+), or none.

- Remote security control

– Using RADIUS

See the “Configuring the RADIUS, TACACS+, and LDAP Server” section

– Using TACACS+

See the “Configuring the RADIUS, TACACS+, and LDAP Server” section

- Local security control.

See the “Local AAA Services” section.

These security features can also be configured for the following scenarios:

- iSCSI authentication

See the IP Services Configuration Guide, Cisco DCNM for SAN.

- Fibre Channel Security Protocol (FC-SP) authentication

See Chapter8, “Configuring FC-SP and DHCHAP”

SNMP Security Options

The SNMP agent supports security features for SNMPv1, SNMPv2c, and SNMPv3. Normal SNMP security features apply to all applications that use SNMP (for example, Cisco MDS 9000 DCNM for SAN).

SNMP security options also apply to DCNM for SAN and Device Manager.

See the Cisco MDS 9000 NX-OS Family System Management Configuration Guide for more information on the SNMP security options.

for information on DCNM for SAN and Device Manager.

Switch AAA Functionalities

Using the CLI or DCNM for SAN (DCNM-SAN), or an SNMP application, you can configure AAA switch functionalities on any switch in the Cisco MDS 9000 Family.

This section includes the following topics:

- Authentication

- Authorization

- Accounting

- Remote AAA Services

- Remote Authentication Guidelines

- Server Groups

- Error-Enabled Status

- Authentication and Authorization Process

Authentication

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

Note When you log in to a Cisco MDS switch successfully using DCNM-SAN or Device Manager through Telnet or SSH and if that switch is configured for AAA server-based authentication, a temporary SNMP user entry is automatically created with an expiry time of one day. The switch authenticates the SNMPv3 protocol data units (PDUs) with your Telnet or SSH login name as the SNMPv3 user. The management station can temporarily use the Telnet or SSH login name as the SNMPv3 auth and priv passphrase. This temporary SNMP login is only allowed if you have one or more active MDS shell sessions. If you do not have an active session at any given time, your login is deleted and you will not be allowed to perform SNMPv3 operations.

Note DCNM-SAN does not support AAA passwords with trailing white space, for example “passwordA.”

Authorization

The following authorization roles exist in all Cisco MDS switches:

- Network operator (network-operator)—Has permission to view the configuration only. The operator cannot make any configuration changes.

- Network administrator (network-admin)— Has permission to execute all commands and make configuration changes. The administrator can also create and customize up to 64 additional roles.

- Default-role—Has permission to use the GUI (DCNM-SAN and Device Manager). This access is automatically granted to all users for accessing the GUI.

These roles cannot be changed or deleted. You can create additional roles and configure the following options:

- Configure role-based authorization by assigning user roles locally or using remote AAA servers.

- Configure user profiles on a remote AAA server to contain role information. This role information is automatically downloaded and used when the user is authenticated through the remote AAA server.

Note If a user belongs only to one of the newly created roles and that role is subsequently deleted, then the user immediately defaults to the network-operator role.

Accounting

The accounting feature tracks and maintains a log of every management configuration used to access the switch. This information can be used to generate reports for troubleshooting and auditing purposes. Accounting logs can be stored locally or sent to remote AAA servers.

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 switch in the fabric can be managed more easily.

- AAA servers are already deployed widely across enterprises and can be easily adopted.

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

- User role mapping for each switch in the fabric can be managed more easily.

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 implementing 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 the Cisco MDS switch encounters errors from the servers in the first group, it tries the servers in the next server group.

AAA Service Configuration Options

AAA configuration in Cisco MDS 9000 Family switches is service based. You can have separate AAA configurations for the following services:

- Telnet or SSH login (DCNM-SAN and Device Manager login)

- Console login

- iSCSI authentication (see the IP Services Configuration GuideCisco MDS 9000 Family NX-OS IP Services Configuration Guide, Cisco DCNM for SAN).

- FC-SP authentication (see Chapter 8, “Configuring FC-SP and DHCHAP”).

- Accounting

In general, server group, local, and none are the three options that can be specified for any service in an AAA configuration. Each option is tried in the order specified. If all the options fail, local is tried.

Caution Cisco MDS NX-OS supports user names that are created with alphanumeric characters or specific special characters (+ [plus], = [equal], _ [underscore], - [hyphen] , \ [backslash], and . [period]) whether created remotely (using TACACS+ or RADIUS) or locally, provided the user name starts with an alphabetical character. Local user names cannot be created with all numbers or with any special characters (apart from those specified). If a numeric-only user name or a non-supported special character user name exists on an AAA server, and is entered during login, then the user is denied access.

Note Even if local is not specified as one of the options, it is tried by default if all AAA servers configured for authentication are unreachable. User has the flexibility to disable this fallback (See section “Configuring Fallback Mechanism for Authentication” section).

When RADIUS times out, local login is attempted depending on the fallback configuration. For this local login to be successful, a local account for the user with the same password should exist, and the RADIUS timeout and retries should take less than 40 seconds. The user is authenticated if the username and password exist in the local authentication configuration.

provides the related CLI command for each AAA service configuration option.

.

Table 4-1 AAA Service Configuration Commands

AAA Service Configuration Option

Related Command

Telnet or SSH login (Cisco DCNM-SAN and Device Manager login)

Console login

iSCSI authentication

FC-SP authentication

Accounting

Error-Enabled Status

When you log in, the login is processed by rolling over to local user database if the remote AAA servers do not respond. In this situation, the following message is displayed on your screen if you have enabled the error-enabled feature:

Remote AAA servers unreachable; local authentication done.

command.

command.

command (see Example 4-1).

Example 4-1 Displays AAA Authentication Login Information

switch# show aaa authentication login error-enable

enabled

AAA Server Monitoring

An unresponsive AAA server introduces a delay in the processing of AAA requests. An MDS switch can periodically monitor an AAA server to check whether it is responding (or alive) to save time in processing AAA requests. The MDS switch marks unresponsive AAA servers as dead and does not send AAA requests to any dead AAA servers. An MDS switch periodically monitors dead AAA servers and brings them to the alive state once they are responding. This monitoring process verifies that an AAA server is in a working state before real AAA requests are sent its way. Whenever an AAA server changes to the dead or alive state, an SNMP trap is generated and the MDS switch warns the administrator that a failure is taking place before it can impact performance. See Figure 4-1 for AAA server states.

Figure 4-1 AAA Server States

Note The monitoring interval for alive servers and dead servers is different and can be configured by the user. The AAA server monitoring is performed by sending a test authentication request to the AAA server.

The user name and password to be used in the test packet can be configured.

See the “Configuring the RADIUS, TACACS+, and LDAP Server” section and“Displaying RADIUS Server Details” section.

Authentication and Authorization Process

Authentication is the process of verifying the identity of the person managing the switch. This identity verification is based on the user ID and password combination provided by the person managing the switch. The Cisco MDS 9000 Family switches allow you to perform local authentication (using the lookup database) or remote authentication (using one or more RADIUS servers or TACACS+ servers).

Authorization provides access control. It is the process of assembling a set of attributes that describe what the user is authorized to perform. Based on the user ID and password combination, the user is authenticated and authorized to access the network as per the assigned role. You can configure parameters that can prevent unauthorized access by an user, provided the switches use the TACACS+ protocol.

AAA authorization is the process of assembling a set of attributes that describe what the user is authorized to perform. Authorization in the Cisco NX-OS software 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.

Figure 4-2 shows a flow chart of the authorization and authentication process.

Figure 4-2 Switch Authorization and Authentication Flow

Note No more server groups left = no response from any server in all server groups.

No more servers left = no response from any server within this server group.

Global AAA Server Monitoring Parameters

The global AAA server monitoring parameters function as follows:

- When a new AAA server is configured it is monitored using the global test parameters, if defined.

- When global test parameters are added or modified, all the AAA servers, which do not have any test parameters configured, start getting monitored using the new global test parameters.

- When the server test parameters are removed for a server or when the idle-time is set to zero (default value) the server starts getting monitored using the global test parameters, if defined.

- If global test parameters are removed or global idle-time is set to zero, servers for which the server test parameters are present are not affected. However, monitoring stops for all other servers that were previously being monitored using global parameters.

- If the server monitoring fails with the user-specified server test parameters, the server monitoring does not fall back to global test parameters.

LDAP

The Lightweight Directory Access Protocol (LDAP) provides centralized validation of users attempting to gain access to a Cisco NX-OS device. LDAP services are maintained in a database on an LDAP daemon running, typically, on a UNIX or Windows NT workstation. You must have access to and must configure an LDAP server before the configured LDAP features on your Cisco NX-OS device are available.

LDAP provides for separate authentication and authorization facilities. LDAP allows for a single access control server (the LDAP daemon) to provide each service-authentication and authorization-independently. Each service can be tied into 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 LDAP client/server protocol uses TCP (TCP port 389) for transport requirements. Cisco NX-OS devices provide centralized authentication using the LDAP protocol.

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.

LDAP Authentication and Authorization

Clients establish a TCP connection and authentication session with an LDAP server through a simple bind (username and password). As part of the authorization process, the LDAP server searches its database to retrieve the user profile and other information.

You can configure the bind operation to first bind and then search, where authentication is performed first and authorization next, or to first search and then bind. The default method is to first search and then bind.

The advantage of searching first and binding later is that the distinguished name (DN) received in the search result can be used as the user DN during binding rather than forming a DN by prepending the username (cn attribute) with the baseDN. This method is especially helpful when the user DN is different from the username plus the baseDN. For the user bind, the bindDN is constructed as baseDN + append-with-baseDN, where append-with-baseDN has a default value of cn=$userid.

Note As an alternative to the bind method, you can establish LDAP authentication using the compare method, which compares the attribute values of a user entry at the server. For example, the user password attribute can be compared for authentication. The default password attribute type is userPassword.

About RADIUS Server Default Configuration

DCNM-SAN allows you to set up a default configuration that can be used for any RADIUS server that you configure the switch to communicate with. The default configuration includes:

- Encryption type

- Timeout value

- Number of retransmission attempts

- Allowing the user to specify a RADIUS server at login

About the Default RADIUS Server Encryption Type and Preshared Key

You need to configure the RADIUS preshared key to authenticate the switch to the RADIUS server. The length of the key is restricted to 64 characters and can include any printable ASCII characters (white spaces are not allowed). You can configure a global key to be used for all RADIUS server configurations on the switch.

command.

About RADIUS Servers

You can add up to 64 RADIUS servers. RADIUS keys are always stored in encrypted form in persistent storage. The running configuration also displays encrypted keys. When you configure a new RADIUS server, you can use the default configuration or modify any of the parameters to override the default RADIUS configuration.

Configuring the Test Idle Timer

The test idle timer specifies the interval during which a RADIUS server receives no requests before the MDS switch sends out a test packet.

Note The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, periodic RADIUS server monitoring is not performed.

To configure the test idle timer, see “Configuring an LDAP Server” section.

Configuring Test User Name

You can configure a username and password for periodic RADIUS server status testing. You do not need to configure the test username and password to issue test messages to monitor RADIUS servers. You can use the default test username (test) and default password (test).

Note We recommend that the test username not be the same as an existing username in the RADIUS database for security reasons.

To configure the optional username and password for periodic RADIUS server status testing, see “Configuring an LDAP Server” section.

About Validating a RADIUS Server

As of Cisco SAN-OS Release 3.0(1), you can periodically validate a RADIUS server. The switch sends a test authentication to the server using the username and password that you configure. If the server does not respond to the test authentication, then the server is considered non responding.

Note For security reasons we recommend that you do not use a username that is configured on your RADIUS server as a test username.

You can configure this option to test the server periodically, or you can run a one-time only test.

About Vendor-Specific Attributes

The value is a string with the following format:

protocol : attribute separator value *

(asterisk) is for optional attributes.

When you use RADIUS servers to authenticate yourself to a Cisco MDS 9000 Family 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 Cisco NX-OS software:

- Shell protocol—Used in Access-Accept packets to provide user profile information.

- Accounting protocol—Used in Accounting-Request packets. If a value contains any white spaces, it should be put within double quotation marks.

The following attributes are supported by the Cisco NX-OS software:

- roles —This attribute lists all the roles to which the user belongs. The value field is a string storing the list of group names delimited by white space. For example, if you belong to roles vsan-admin and storage-admin , the value field would be “ vsan-admin storage-admin” . This subattribute is sent in the VSA portion of the Access-Accept frames from the RADIUS server, and it can only be used with the shell protocol value. These are two examples using the roles attribute:

, this VSA is flagged as an optional attribute, and other Cisco devices ignore this attribute.

- accountinginfo —This attribute stores additional accounting information besides the attributes covered by a standard RADIUS accounting protocol. This attribute is only sent 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 SNMPv3 on AAA Servers

can be used to specify user’s role mapping using the format:

shell:roles="roleA roleB …"

attribute is not set, the default user role is network-operator.

The VSA format optionally specifies your SNMPv3 authentication and privacy protocol attributes also as follows:

shell:roles="roleA roleB..." snmpv3:auth=SHA priv=AES-128

attribute on the ACS server, MD5 and DES are used by default.

One-Time Password Support

A one-time password (OTP) is a password that is valid for a single login session or transaction. OTPs avoid a number of shortcomings that are associated with usual (static) passwords. The most vital shortcoming that is addressed by OTPs is that, in contrast to static passwords, they are not at risk to replay attacks. If an intruder manages to record an OTP that was already used to log into a service or to conduct an operation, it will not be misused because it is no longer valid.

One-time password applies only to RADIUS and TACACS protocol daemons. In the case of the RADIUS protocol daemon, there is no configuration required from the switch side. In the case of the TACACS protocol, ASCII authentication mode needs to be enabledwhich can be done by the following command.

aaa authentication login ascii-authentication

About TACACS+

TACACS+ is a client/server protocol that uses TCP (TCP port 49) for transport requirements. All switches in the Cisco MDS 9000 Family provide centralized authentication using the TACACS+ protocol. The TACACS+ has the following advantages over RADIUS authentication:

- Provides independent, modular AAA facilities. Authorization can be done without authentication.

- 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.

About TACACS+ Server Default Configuration

DCNM-SAN allows you to set up a default configuration that can be used for any TACACS+ server that you configure the switch to communicate with. The default configuration includes:

- Encryption type

- Preshared key

- Timeout value

- Number of retransmission attempts

- Allowing the user to specify a TACACS+ server at login

About the Default TACACS+ Server Encryption Type and Preshared Key

You need to configure the TACACS+ preshared key to authenticate the switch to the TACACS+ server. The length of the key is restricted to 64 characters and can include any printable ASCII characters (white spaces are not allowed). You can configure a global key to be used for all TACACS+ server configurations on the switch.

option when configuring an individual TACACS+ server.

About TACACS+ Servers

By default, the TACACS+ feature is disabled in all switches in the Cisco MDS 9000 Family. DCNM-SAN or Device Manager enables the TACACS+ feature automatically when you configure a TACACS+ server.

If a secret key is not configured for a configured server, a warning message is issued if a global key is not configured. If a server key is not configured, the global key (if configured) is used for that server.

Note Prior to Cisco MDS SAN-OS Release 2.1(2), you can use the dollar sign ($) in the key but the key must be enclosed in double quotes, for example “k$”. The percent sign (%) is not allowed. In Cisco MDS SAN-OS Release 2.1(2) and later, you can use the dollar sign ($) without double quotes and the percent sign (%) in global secret keys.

You can configure global values for the secret key for all TACACS+ servers.

Note If secret keys are configured for individual servers, those keys override the globally configured key.

Password Aging Notification through TACACS+ Server

Password aging notification is initiated when the user authenticates to a Cisco MDS 9000 switch via a TACACS+ account. The user is notified when a password is about to expire or has expired. If the password has expired, user is prompted to change the password.

Note As of Cisco MDS SAN-OS Release 3.2(1), only TACACS+ supports password aging notification. If you try to use RADIUS servers by enabling this feature, RADIUS generates a SYSLOG message and authentication falls back to the local database.

Password aging notification facilitates the following:

- Password change—You can change your password by entering a blank password.

- Password aging notification—Notifies password aging. Notification happens only if the AAA server is configured and MSCHAP and MSCHAPv2 is disabled.

- Password change after expiration—Initiates password change after the old password expires. Initiation happens from the AAA server.

Note Password aging notification fails if you do not disable MSCHAP and MSCHAPv2 authentication.

To enable the password aging option in the AAA server, enter the following command:

aaa authentication login ascii-authentication

To determine whether or not password aging notification is enabled or disabled in the AAA server, enter the following command:

show aaa authentication login ascii-authentication

About Validating a TACACS+ Server

As of Cisco SAN-OS Release 3.0(1), you can periodically validate a TACACS+ server. The switch sends a test authentication to the server using the test username and test password that you configure. If the server does not respond to the test authentication, then the server is considered nonresponding.

Note We recommend that you do not configure the test user on your TACACS+ server for security reasons.

You can configure this option to test the server periodically, or you can run a one-time only test.

Periodically Validating a TACACS+ Server

To configure the switch to periodically test a TACACS+ server using DCNM-SAN, see the “Configuring the RADIUS, TACACS+, and LDAP Server” section.

About Users Specifying a TACACS+ Server at Login

is the name of a configured TACACS+ server.

Supported TACACS+ Server Parameters

The Cisco NX-OS software currently supports the following parameters for the listed TACACS+ servers:

- TACACS+

cisco-av-pair=shell:roles="network-admin"

- Cisco ACS TACACS+

shell:roles="network-admin"

shell:roles*"network-admin"

cisco-av-pair*shell:roles="network-admin"

cisco-av-pair*shell:roles*"network-admin"

cisco-av-pair=shell:roles*"network-admin"

- Open TACACS+

cisco-av-pair*shell:roles="network-admin"

cisco-av-pair=shell:roles*"network-admin"

About Bypassing a Nonresponsive Server

As of Cisco SAN-OS Release 3.0(1), you can bypass a nonresponsive AAA server within a server group. If the switch detects a nonresponsive server, it will bypass that server when authenticating users. Use this feature to minimize login delays caused by a faulty server. Instead of sending a request to a nonresponsive server and waiting for the authentication request to timeout, the switch sends the authentication request to the next server in the server group. If there are no other responding servers in the server group, the switch continues to attempt authentications against the nonresponsive server.

AAA Server Distribution

Configuration for RADIUS and TACACS+ AAA on an MDS switch can be distributed using the Cisco Fabric Services (CFS). The distribution is disabled by default (see the Cisco MDS 9000 Family NX-OS System Management Configuration GuideSystem Management Configuration Guide, Cisco DCNM for SAN).

After enabling the distribution, the first server or global configuration starts an implicit session. All server configuration commands entered thereafter are stored in a temporary database and applied to all switches in the fabric (including the originating one) when you explicitly commit the database. The various server and global parameters are distributed, except the server and global keys. These keys are unique secrets to a switch and should not be shared with other switches.

Note Server group configurations are not distributed.

Note For an MDS switch to participate in AAA server configuration distribution, it must be running Cisco MDS SAN-OS Release 2.0(1b) or later, or Cisco NX-OS Release 4.1(1).

Starting a Distribution Session on a Switch

A distribution session starts the moment you begin a RADIUS or TACACS+ server or global configuration. For example, the following tasks start an implicit session:

- Specifying the global timeout for RADIUS servers.

- Specifying the global timeout for TACACS+ servers.

Note After you issue the first configuration command related to AAA servers, all server and global configurations that are created (including the configuration that caused the distribution session start) are stored in a temporary buffer, not in the running configuration.

CHAP Authentication

Challenge Handshake Authentication Protocol (CHAP) is a challenge-response authentication protocol that uses the industry-standard Message Digest 5 (MD5) hashing scheme to encrypt the response. CHAP is used by various vendors of network access servers and clients. A server running routing and remote access supports CHAP so that remote access clients that require CHAP are authenticated. CHAP is supported as an authentication method in this release.

MSCHAP Authentication

Microsoft Challenge Handshake Authentication Protocol (MSCHAP) is the Microsoft version of CHAP.

Cisco MDS 9000 Family switches allow user logins to perform remote authentication using different versions of MSCHAP. MSCHAP is used for authentication on a RADIUS or TACACS+ server, while MSCHAPv2 is used for authentication on a RADIUS server.

About Enabling MSCHAP

shows the RADIUS vendor-specific attributes required for MSCHAP.

Table 4-2 MSCHAP RADIUS Vendor-Specific Attributes

Vendor-ID Number

Vendor-Type Number

Vendor-Specific Attribute

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 MS-CHAP user in response to the challenge. It is only used in Access-Request packets.

Local AAA Services

The system maintains the username and password locally and stores the password information in encrypted form. You are authenticated based on the locally stored user information.

Accounting Services

Accounting refers to the log information that is kept for each management session in a switch. This information may be used to generate reports for troubleshooting and auditing purposes. Accounting can be implemented locally or remotely (using RADIUS). The default maximum size of the accounting log is 250,000 bytes and cannot be changed.

Tip The Cisco MDS 9000 Family switch uses interim-update RADIUS accounting-request packets to communicate accounting log information to the RADIUS server. The RADIUS server must be appropriately configured to log the information communicated in these packets. Several servers typically have log update/watchdog packets flags in the AAA client configuration. Turn on this flag to ensure proper RADIUS accounting.

Note Configuration operations are automatically recorded in the accounting log if they are performed in configuration mode. Additionally, important system events (for example, configuration save and system switchover) are also recorded in the accounting log.

Defining Roles on the Cisco Secure ACS 5.x GUI

Enter the following in the GUI under Policy Elements:

Table 4-3 Role Definitions

Attribute

Requirement

Value

shell:roles

Optional

network-admin

Defining Custom Attributes for Roles

. The following example illustrates how to specify roles using this attribute:

cisco-av-pair=shell:roles=”network-admin vsan-admin”

You can also configure optional custom attributes to avoid conflicts with non-MDS Cisco switches using the same AAA servers.

cisco-av-pair*shell:roles="network-admin vsan-admin"

Additional custom attribute shell:roles are also supported:

shell:roles="network-admin vsan-admin"

or

shell:roles*"network-admin vsan-admin”

Note TACACS+ custom attributes can be defined on an Access Control Server (ACS) for various services (for example, shell). Cisco MDS 9000 Family switches require the TACACS+ custom attribute for the service shell to be used for defining roles.

Guidelines and Limitations

This section has the following topics:

- Remote Authentication Guidelines

- Guidelines and Limitations for LDAP

- Merge Guidelines for RADIUS and TACACS+ Configurations

Remote Authentication Guidelines

If you prefer using remote AAA servers, follow these guidelines:

- A minimum of one AAA server should be IP reachable.

- Be sure to configure a desired local AAA policy as this policy is used if all AAA servers are not reachable.

- AAA servers are easily reachable if an overlay Ethernet LAN is attached to the switch (see the IP Services Configuration Guide, Cisco DCNM for SANCisco MDS 9000 Family NX-OS Configuration Guide). We recommend this method.

SAN networks connected to the switch should have at least one gateway switch connected to the Ethernet LAN reaching the AAA servers.

Guidelines and Limitations for LDAP

LDAP has the following guidelines and limitations:

- You can configure a maximum of 64 LDAP servers on the Cisco NX-OS device.

- Cisco NX-OS supports only LDAP version 3.

- Cisco NX-OS supports only these LDAP servers:

– OpenLDAP

– Microsoft Active Directory

- LDAP over Secure Sockets Layer (SSL) supports only SSL version 3 and Transport Layer Security (TLS) version 1.

- If you have a user account configured on the local Cisco NX-OS device that has the same name as a remote user account on an AAA server, the Cisco NX-OS software applies the user roles for the local user account to the remote user, not the user roles configured on the AAA server.

Merge Guidelines for RADIUS and TACACS+ Configurations

The RADIUS and TACACS+ server and global configuration are merged when two fabrics merge. The merged configuration is applied to CFS distribution-enabled switches.

When merging the fabric, be aware of the following conditions:

- The server groups are not merged.

- The server and global keys are not changed during the merge.

- The merged configuration contains all servers found on all CFS enabled switches.

- The timeout and retransmit parameters of the merged configuration are the largest values found per server and global configuration.

Note Test parameter will be distributed via CFS for TACACS+ Daemon only. If the fabric contains only Cisco NX-OS Release 5.0 devices, then the test parameters will be distributed. If the fabric contains devices running Release 5.0 and some running Release 4.x, the test parameters are not distributed.

Caution If there is a conflict between two switches in the server ports configured, the merge fails.

Default Settings

lists the default settings for LDAP parameters.

Table 4-4 Default LDAP Parameter Settings

Parameters

Default

LDAP

Disabled

LDAP authentication method

First search and then bind

LDAP authentication mechanism

Plain

Dead-interval time

0 minutes

Timeout interval

5 seconds

Idle timer interval

60 minutes

Periodic server monitoring username

test

Periodic server monitoring password

Cisco

lists the default settings for all switch security features in any switch.

Table 4-5 Default Switch Security Settings

Parameters

Default

Roles in Cisco MDS switches

Network operator (network-operator)

AAA configuration services

Local

Authentication port

1812

Accounting port

1813

Preshared key communication

Clear text

RADIUS server timeout

1 (one) second

RADIUS server retries

Once

Authorization

Disabled

aaa user default role

enabled

RADIUS server directed requests

Disabled

TACACS+

Disabled

TACACS+ servers

None configured

TACACS+ server timeout

5 seconds

TACACS+ server directed requests

Disabled

AAA server distribution

Disabled

Accounting log size

250 KB

Configuring the RADIUS, TACACS+, and LDAP Server

Cisco MDS 9000 Family switches can use the RADIUS protocol to communicate with remote AAA servers. You can configure multiple RADIUS servers and server groups and set timeout and retry counts.

RADIUS is a distributed client/server protocol that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco MDS 9000 Family switches and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.

This section defines the RADIUS operation, identifies its network environments, and describes its configuration possibilities.

A Cisco MDS switch uses the Terminal Access Controller Access Control System Plus (TACACS+) protocol to communicate with remote AAA servers. You can configure multiple TACACS+ servers and set timeout values.

This section includes the following topics:

- Authorizing and Authenticating the Switch

- Configuring Role-based Authorization on TACACS+ Server

- Configuring Fallback Mechanism for Authentication

- Configuring AAA Server Monitoring Parameters Globally

- Enabling LDAP

- Configuring LDAP Server Hosts

- Configuring the RootDN for an LDAP Server

- Configuring LDAP Server Groups

- Configuring the Global LDAP Timeout Interval

- Configuring the Timeout Interval for an LDAP Server

- Configuring the Global LDAP Server Port

- Configuring TCP Ports

- Configuring LDAP Search Maps

- Configuring the LDAP Dead-Time Interval

- Configuring AAA Authorization on LDAP Servers

- Disabling LDAP

- Setting the RADIUS Server Address

- Configuring the Default RADIUS Server Encryption Type and Preshared Key

- Setting the RADIUS Server Timeout Interval

- Setting the Default RADIUS Server Timeout Interval and Retransmits

- Configuring an LDAP Server

- Validating a RADIUS Server

- Sending RADIUS Test Messages for Monitoring

- Allowing Users to Specify a RADIUS Server at Login

- Enabling TACACS+

- Setting the Default TACACS+ Server Encryption Type and Preshared Key

- Setting the TACACS+ Server Address

- Setting the Global Secret Key

- Setting the Default TACACS+ Server Timeout Interval and Retransmits

- Setting the Timeout Value

- Configuring a TACACS+ Server

- Sending TACACS+ Test Messages for Monitoring

- Allowing Users to Specify a TACACS+ Server at Login

- Clearing TACACS+ Server Statistics

- Configuring Server Groups

- Enabling AAA Server Distribution

- Committing the Distribution

- Discarding the Distribution Session

- Clearing Sessions

- Enabling CHAP Authentication

- Enabling MSCHAP Authentication

- Configuring Cisco Access Control Servers

Authorizing and Authenticating the Switch

Detailed Steps

To authorize and authenticate the switch, follow these steps:

Step 1 Log in to the required switch in the Cisco MDS 9000 Family, using the Telnet, SSH, DCNM-SAN or Device Manager, or console login options.

Step 2 When you have configured server groups using the server group authentication method, an authentication request is sent to the first AAA server in the group.

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

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

- If all configured methods fail, then by default local database is used for authentication. The next section will describe the way to disable this fallback.

Step 3 When you are successfully authenticated through a remote AAA server, then the following possible actions are taken:

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

- 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.

- If user roles are not successfully retrieved from the remote AAA server, then the user is assigned the network-operator role if the show aaa user default-role command is enabled. You are denied access if this command is disabled.

Step 4 When your user name and password are successfully authenticated locally, you are allowed to log in, and you are assigned the roles configured in the local database.

Configuring Role-based Authorization on TACACS+ Server

Detailed Steps

To configure role-based authorization on TACACS+ server, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables configuration of authorization methods.

Step 3

Enables authorization for all commands under config mode Layer2 and Layer3.

Step 4

Enables specified TACACS+ server group authorization.

Step 5

Enables AAA authorization for all EXEC mode commands.

Step 6

Enables specified TACACS+ server group authorization.

Step 7

Enables default TACACS+ server group authorization.Authorization is based on the local-user-database.

Step 8

switch(config)# no aaa authorization command default group tac1

Removes authorization for a specified function for the authenticated user.

Note Authorization configuration is provided only for authentication done using TACACS+ server.

Note The ‘none’ option from aaa authorization methods has been deprecated. If you did an upgrade from 4.x image and ‘none’ was configured as one of the authorization methods, it is be replaced with local. The functionality remains the same.

Configuring Fallback Mechanism for Authentication

You can enable or disable fallback to the local database in case the remote authentication is set and all of the AAA servers are unreachable (authentication error). The fallback is set to local by default in case of an authentication error. You can disable this fallback for both console and SSH or Telnet login. Disabling this fallback tightens the authentication security.

Detailed Steps

To configure the fallback mechanism, follow this step:

Step 1 Enter the show run aaa all command to verify that the default fallback is enabled for both the default and console login.

Disabling fallback will print a warning message.

The CLI syntax and behavior is as follows:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config)# sh run aaa all

aaa authentication login default fallback error local

aaa authentication login console fallback error local

Displays the default fallback behavior.

Step 3

WARNING!!! Disabling fallback can lock your switch.

Disables the fallback to local database for authentication.

Note Replace default with console in this command to disable fallback to console.

Caution If fallback is disabled for both the default and console, remote authentication is enabled and servers are unreachable and then the switch will be locked.

Configuring AAA Server Monitoring Parameters Globally

The AAA server monitoring parameters can be configured globally for all servers or individually for a specific server. This section explains how the global configuration can be set. The global configurations will apply to all servers that do not have individual monitoring parameters defined. For any server, the individual test parameter defined for that particular server will always get precedence over the global settings.

Detailed Steps

Use the following commands to configure the global monitoring parameters for RADIUS servers:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Sets global deadtime for RADIUS servers to 10 minutes.

Acceptable Range: 0 to 1440 minutes.

Step 3

Sets global timeout for RADIUS servers to 20 seconds.

Acceptable Range: 1 to 60 seconds.

Step 4

switch(config)# radius-server retransmit 2

Sets global retransmit count for RADIUS servers to 2.

Acceptable Range 0 to 5

Step 5

Globally configures test parameters for the RADIUS servers.

Disables global test parameters for the RADIUS servers.

Note Replace “radius” with “tacacs” in the steps above to get equivalent commands for TACACS server global test parameter configurations.

Enabling LDAP

By default, the LDAP feature is disabled on the Cisco NX-OS device. You must explicitly enable the LDAP feature to access the configuration and verification commands for authentication.

Prerequisites

LDAP has the following prerequisites:

- Obtain the IPv4 or IPv6 addresses or hostnames for the LDAP servers.

- Ensure that the Cisco NX-OS device is configured as an LDAP client of the AAA servers.

Detailed Steps

To enable LDAP, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Enables LDAP.

Step 3

switch#

Exits configuration mode.

Step 4

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

Configuring LDAP Server Hosts

To access a remote LDAP server, you must configure the IP address or the hostname for the LDAP server on the Cisco NX-OS device. You can configure up to 64 LDAP servers.

Note By default, when you configure an LDAP server IP address or hostname on the Cisco NX-OS device, the LDAP server is added to the default LDAP server group. You can also add the LDAP server to another LDAP server group.

Detailed Steps

To configure LDAP server hosts, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the IPv4 or IPv6 address or hostname for an LDAP server.

The enable-ssl keyword ensures the integrity and confidentiality of the transferred data by causing the LDAP client to establish a Secure Sockets Layer (SSL) session prior to sending the bind or search request.

Step 3

switch#

Exits configuration mode.

Step 4

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

Configuring the RootDN for an LDAP Server

You can configure the root designated name (DN) for the LDAP server database. The rootDN is used to bind to the LDAP server to verify its state.

Detailed Steps

To configure the RootDN for an LDAP server, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the rootDN for the LDAP server database and the bind password for the root.

Optionally specifies the TCP port to use for LDAP messages to the server. The range is from 1 to 65535, and the default TCP port is the global value or 389 if a global value is not configured. Also specifies the timeout interval for the server. The range is from 1 to 60 seconds, and the default timeout is the global value or 5 seconds if a global value is not configured.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring LDAP Server Groups

You can specify one or more remote AAA servers to authenticate users using server groups. All members of a group must be configured to use LDAP. The servers are tried in the same order in which you configure them.

You can configure these server groups at any time, but they take effect only when you apply them to an AAA service.

Detailed Steps

To configure the LDAP server groups, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters global configuration mode.

Step 2

switch(config-ldap)#

Creates an LDAP server group and enters the LDAP server group configuration mode for that group.

Step 3

Configures the LDAP server as a member of the LDAP server group.

If the specified LDAP server is not found, configure it using the ldap-server host command and retry this command.

Step 4

(Optional) Performs LDAP authentication using the bind or compare method. The default LDAP authentication method is the bind method using first search and then bind.

Step 5

(Optional) Enables group validation. The group name should be configured in the LDAP server. Users can login through public-key authentication only if the username is listed as a member of this configured group in the LDAP server.

Step 6

h

(Optional) Enables users to login only if the user profile lists the subject-DN of the user certificate as authorized for login.

Step 7

switch#

Exits configuration mode.

Step 8

(Optional) Displays the LDAP server group configuration.

Step 9

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

Configuring the Global LDAP Timeout Interval

You can set a global timeout interval that determines how long the Cisco NX-OS device waits for responses from all LDAP servers before declaring a timeout failure.

Detailed Steps

To configure the global LDAP timeout interval, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the timeout interval for LDAP servers. The default timeout interval is 5 seconds. The range is from 1 to 60 seconds.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring the Timeout Interval for an LDAP Server

You can set a timeout interval that determines how long the Cisco NX-OS device waits for responses from an LDAP server before declaring a timeout failure.

Detailed Steps

To configure the timeout interval for an LDAP server, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the timeout interval for a specific server. The default is the global value.

Note The timeout interval value specified for an LDAP server overrides the global timeout interval value specified for all LDAP servers.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring the Global LDAP Server Port

You can configure a global LDAP server port through which clients initiate TCP connections. By default, Cisco NX-OS devices use port 389 for all LDAP requests.

Detailed Steps

To configure the global LDAP server port, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the global TCP port to use for LDAP messages to the server. The default TCP port is 389. The range is from 1 to 65535.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring TCP Ports

You can configure another TCP port for the LDAP servers if there are conflicts with another application. By default, Cisco NX-OS devices use port 389 for all LDAP requests.

Detailed Steps

To configure the TCP ports, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Specifies the TCP port to use for LDAP messages to the server. The default TCP port is 389. The range is from 1 to 65535. Optionally specifies the timeout interval for the server. The range is from 1 to 60 seconds, and the default timeout is the global value or 5 seconds if a global value is not configured.

Note The timeout interval value specified for an LDAP server overrides the global timeout interval value specified for all LDAP servers.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring LDAP Search Maps

You can configure LDAP search maps to send a search query to the LDAP server. The server searches its database for data meeting the criteria specified in the search map.

Detailed Steps

To configure the LDAP search maps, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

switch(config-ldap-search-map)#

Configures an LDAP search map.

Step 3

(Optional) Configures the attribute name, search filter, and base-DN for the user profile, trusted certificate, CRL, certificate DN match, public key match, or user-switchgroup lookup search operation. These values are used to send a search query to the LDAP server.

Step 4

switch(config)#

Exits LDAP search map configuration mode.

Step 5

(Optional) Displays the configured LDAP search maps.

Step 6

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

Configuring the LDAP Dead-Time Interval

You can configure the dead-time interval for all LDAP servers. The dead-time interval specifies the time that the Cisco NX-OS device waits, after declaring that an LDAP server is dead, before sending out a test packet to determine if the server is now alive.

Note When the dead-time interval is 0 minutes, LDAP servers are not marked as dead even if they are not responding. You can configure the dead-time interval per group.

Detailed Steps

To configure the LDAP dead-time interval, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Configures the global dead-time interval. The default value is 0 minutes. The range is from 1 to 60 minutes.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the LDAP server configuration.

Step 5

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

Configuring AAA Authorization on LDAP Servers

You can configure the default AAA authorization method for LDAP servers.

Detailed Steps

To configure the AAA authorization on LDAP servers, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Configures the default AAA authorization method for the LDAP servers.

The ssh-certificate keyword configures LDAP or local authorization with certificate authentication, and the ssh-publickey keyword configures LDAP or local authorization with the SSH public key. The default authorization is local authorization, which is the list of authorized commands for the user’s assigned role.

method uses the local database for authorization.

Step 3

switch#

Exits configuration mode.

Step 4

(Optional) Displays the AAA authorization configuration. The all keyword displays the default values.

Step 5

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

Disabling LDAP

When you disable LDAP, all related configurations are automatically discarded.

Detailed Steps

To disable LDAP, follow these steps:

Step 1

switch(config)#

Enters global configuration mode.

Step 2

Disables LDAP.

Step 3

switch#

Exits configuration mode.

Step 4

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

For detailed information about the fields in the output from this command, see the Cisco MDS 9000 Family Command Reference, Release 5.0(1a).

Setting the RADIUS Server Address

You can add up to 64 RADIUS servers. RADIUS keys are always stored in encrypted form in persistent storage. The running configuration also displays encrypted keys.

Detailed Steps

To specify the host RADIUS server IPv4 address and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

command. In this example, the host is 10.10.0.0 and the key is HostKey.

Step 3

Specifies the destination UDP port number to which the RADIUS authentication messages should be sent. In this example, the host is 10.10.0.0 and the authentication port is 2003. The default authentication port is 1812, and the valid range is 0 to 65366.

Step 4

Specifies the destination UDP port number to which RADIUS accounting messages should be sent. The default accounting port is 1813, and the valid range is 0 to 65366.

Step 5

Specifies this server to be used only for accounting purposes.
options are specified, the server is used for both accounting and authentication purposes.

Step 6

Specifies a clear text key for the specified server. The key is restricted to 64 characters.

Specifies an encrypted key for the specified server. The key is restricted to 64 characters.

To specify the host RADIUS server IPv6 address and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

command. In this example, the host is 2001:0DB8:800:200C::417A and the key is HostKey.

Step 3

Specifies the destination UDP port number to which the RADIUS authentication messages should be sent. In this example, the host is 2001:0DB8:800:200C::417A and the authentication port is 2003. The default authentication port is 1812, and the valid range is 0 to 65366.

Step 4

Specifies the destination UDP port number to which RADIUS accounting messages should be sent. The default accounting port is 1813, and the valid range is 0 to 65366.

Step 5

Specifies this server to be used only for accounting purposes.
options are specified, the server is used for both accounting and authentication purposes.

Step 6

Specifies a clear text key for the specified server. The key is restricted to 64 characters.

Specifies an encrypted key for the specified server. The key is restricted to 64 characters.

To specify the host RADIUS server DNS name and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

command. In this example, the host is radius2 and the key is HostKey.

Step 3

Specifies the destination UDP port number to which the RADIUS authentication messages should be sent. In this example, the host is radius2 and the authentication port is 2003. The default authentication port is 1812, and the valid range is 0 to 65366.

Step 4

Specifies the destination UDP port number to which RADIUS accounting messages should be sent. The default accounting port is 1813, and the valid range is 0 to 65366.

Step 5

Specifies this server to be used only for accounting purposes.
options are specified, the server is used for both accounting and authentication purposes.

Step 6

Specifies a clear text key for the specified server. The key is restricted to 64 characters.

Specifies an encrypted key for the specified server. The key is restricted to 64 characters.

Configuring the Default RADIUS Server Encryption Type and Preshared Key

Detailed Steps

To configure the RADIUS preshared key, follow these steps:

Command

Purpose

Step 1

switch# config t

Enters configuration mode.

Step 2

Configures a preshared key (AnyWord) to authenticate communication between the RADIUS client and server. The default is clear text.

Configures a preshared key (AnyWord) specified in clear text (indicated by 0) to authenticate communication between the RADIUS client and server.

Configures a preshared key (specified in encrypted text) specified in encrypted text (indicated by 7) to authenticate communication between the RADIUS client and server.

To configure the default RADIUS server encryption type and preshared key, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

from the AuthType drop-down menu.

Step 4 Set the key in the Auth Key field.

icon to save the changes.

Setting the RADIUS Server Timeout Interval

You can configure a global timeout value between transmissions for all RADIUS servers.

Note If timeout values are configured for individual servers, those values override the globally configured values.

Detailed Steps

To specify the timeout values between retransmissions to the RADIUS servers, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the global timeout period in seconds for the switch to wait for a response from all TACACS+ servers before the switch declares a timeout failure. The time ranges from 1 to 1440 seconds.

Reverts the transmission time to the default value (1 second).

Setting the Default RADIUS Server Timeout Interval and Retransmits

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. You can also configure the timeout value for the RADIUS server.

Detailed Steps

To specify the number of times that RADIUS servers should try to authenticate a user, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the number of times (3) the switch tries to connect to a RADIUS server(s) before reverting to local authentication.

Reverts to the default retry count (1).

To configure the number of retransmissions and the time between retransmissions to the RADIUS servers, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

You see the RADIUS default settings.

Step 3 Fill in the Timeout and Retransmits fields for authentication attempts.

icon to save the changes.

Configuring the Test Idle Timer

The test idle timer specifies the interval during which a RADIUS server receives no requests before the MDS switch sends out a test packet.

Note The default idle timer value is 0 minutes. When the idle time interval is 0 minutes, periodic RADIUS server monitoring is not performed.

Detailed Steps

To configure the idle timer, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the test idle time interval value in minutes. The valid range is 1 to 1440 minutes.

Step 3

Reverts to the default value (0 minutes).

Configuring Test User Name

You can configure a username and password for periodic RADIUS server status testing. You do not need to configure the test username and password to issue test messages to monitor RADIUS servers. You can use the default test username (test) and default password (test).

Note We recommend that the test username not be the same as an existing username in the RADIUS database for security reasons.

Detailed Steps

To configure the optional username and password for periodic RADIUS server status testing, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the test user (testuser) with the default password (test). The default user name is test.

Removes the test user name (testuser).

Configures the test user (testuser) and assigns a strong password.

Configuring the Dead Timer

The dead timer specifies the interval that the MDS switch waits, after declaring that a RADIUS server is dead, before sending out a test packet to determine if the server is now alive.

Note The default dead timer value is 0 minutes. When the dead timer interval is 0 minutes, RADIUS server monitoring is not performed unless the RADIUS server is part of a server group and the dead-time interval for the group is greater than 0 minutes. (See the “Server Groups” section).

Note If the dead timer of a dead RADIUS server expires before it is sent a RADIUS test message, that server is marked as alive again even if it is still not responding. To avoid this scenario, configure a test user with a shorter idle time than the dead timer time.

Detailed Steps

To configure the dead timer, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the dead timer interval value in minutes. The valid range is 1 to 1440 minutes.

Step 3

Reverts to the default value (0 minutes).

Configuring an LDAP Server

Detailed Steps

To configure an LDAP server and all of its options, follow these steps:

.

You see the LDAP configuration in the Information pane.

tab.

You see any existing RADIUS servers.

to add a new LDAP server.

You see the Create LDAP Server dialog box.

Figure 4-3 LDAP Server Creation

Step 4 Select the switches that you want to assign as LDAP servers.

Step 5 Assign an index number to identify the LDAP server.

Step 6 Select the IP address type for the LDAP server.

Step 7 Fill in the IP address or name for the LDAP server.

Step 8 (Optional) Modify the authentication and accounting ports used by this LDAP server.

Step 9 Select the appropriate key type for the LDAP server.

Step 10 Select the TimeOut value in seconds. The valid range is 0 to 60 seconds.

Step 11 Select the number of times the switch tries to connect to an LDAP server(s) before reverting to local authentication.

Step 12 Enter the test idle time interval value in minutes. The valid range is 1 to 1440 minutes.

Step 13 Enter the test user with the default password. The default username is test.

to save these changes.

Creating LDAP Search Map

To create an LDAP search map, follow these steps:

.

You see the LDAP configuration in the Information pane.

tab.

to add a new LDAP search map.

Step 4 Enter the LDAP search map name for the Name field.

Step 5 Select the appropriate search type for the Type field.

Step 6 Enter the base domain name for the BaseDN field.

Step 7 Enter the filter value for the Filter field.

Step 8 Enter the attribute value for the Attribute field.

Step 9 Click Create to save the changes.

Configuring a RADIUS Server

Detailed Steps

To configure a RADIUS server and all its options, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

You see any existing RADIUS servers.

to add a new RADIUS server.

You see the Create RADIUS Server dialog box shown in Figure 4-4.

Figure 4-4 Create RADIUS Server

Step 4 Select the switches that you want to assign as RADIUS servers.

Step 5 Assign an index number to identify the RADIUS server.

Step 6 Select the IP address type for the RADIUS server.

Step 7 Fill in the IP address or name for the RADIUS server.

Step 8 (Optional) Modify the authentication and accounting ports used by this RADIUS server.

Step 9 Select the appropriate key type for the RADIUS server.

Step 10 Select the TimeOut value in seconds. The valid range is 0 to 60 seconds.

Step 11 Select the number of times the switch tries to connect to a RADIUS server(s) before reverting to local authentication.

Step 12 Enter the test idle time interval value in minutes. The valid range is 1 to 1440 minutes.

Step 13 Enter the test user with the default password. The default username is test.

to save these changes.

Validating a RADIUS Server

Detailed Steps

To configure the switch to periodically test a RADIUS server, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

You see any existing RADIUS servers.

to add a new RADIUS server.

You see the Create RADIUS Server dialog box (see Figure 4-4).

Step 4 Fill in the IP address.

Step 5 Modify the authentication and accounting ports used by this RADIUS server.

.

Step 7 Set the IdleTime field for the time that the server is idle before you send a test authentication.

to save these changes.

Sending RADIUS Test Messages for Monitoring

You can manually send test messages to monitor a RADIUS server.

Detailed Steps

To send the test message to the RADIUS server, follow this step:

Command

Purpose

Step 1

Sends a test message to a RADIUS server using the default username (test) and password (test).

Sends a test message to a RADIUS server using a configured test username (testuser) and password (Ur2Gd2BH).

Note A configured username and password is optional (see the “Configuring Test User Name” section).

Allowing Users to Specify a RADIUS Server at Login

is the name of a configured RADIUS server.

Detailed Steps

To allow users logging into an MDS switch to select a RADIUS server for authentication, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Allows users to specify a RADIUS server to send the authentication request when logging in.

Reverts to sending the authentication request to the first server in the server group (default).

To allow users logging into an MDS switch to select a RADIUS server for authentication, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

You see the RADIUS default settings.

check box for the RADIUS server.

icon to save the changes.

Enabling TACACS+

By default, the TACACS+ feature is disabled in all switches in the Cisco MDS 9000 Family. You must explicitly enable the TACACS+ feature to access the configuration and verification commands for fabric authentication. When you disable this feature, all related configurations are automatically discarded.

Detailed Steps

To enable TACACS+ for a Cisco MDS switch, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables the TACACS+ in this switch.

Disables (default) the TACACS+ in this switch.

Setting the Default TACACS+ Server Encryption Type and Preshared Key

Detailed Steps

To configure the default TACACS+ server encryption type and preshared key, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab.

tab.

You see the TACACS+ default settings.

from the AuthType drop-down menu and set the key in the Auth Key field.

icon to save the changes.

Setting the TACACS+ Server Address

If a secret key is not configured for a configured server, a warning message is issued if a global key is not configured. If a server key is not configured, the global key (if configured) is used for that server (see the “Setting the Default TACACS+ Server Timeout Interval and Retransmits” section).

Note You can use the dollar sign ($) and the percent sign (%) in global secret keys.

Detailed Steps

To configure the TACACS+ server IPv4 address and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the TACACS+ server identified by the specified IPv4 address.

Deletes the specified TACACS+ server identified by the IPv4 address. By default, no server is configured.

Step 3

Configures the TCP port for all TACACS+ requests.

Reverts to the factory default of using port 49 for server access.

Step 4

Configures the TACACS+ server identified by the specified domain name and assigns the secret key.

Step 5

Configures the timeout period for the switch to wait for a response from the specified server before it declares a timeout failure.

To configure the TACACS+ server IPv6 address and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

warning: no key is configured for the host

Configures the TACACS+ server identified by the specified IPv6 address.

Deletes the specified TACACS+ server identified by the IPv6 address. By default, no server is configured.

Step 3

Configures the TCP port for all TACACS+ requests.

Reverts to the factory default of using port 49 for server access.

Step 4

Configures the TACACS+ server identified by the specified domain name and assigns the secret key.

Step 5

Configures the timeout period for the switch to wait for a response from the specified server before it declares a timeout failure.

To configure the TACACS+ server DNS name and other options, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

warning: no key is configured for the host

Configures the TACACS+ server identified by the specified DNS name.

Deletes the specified TACACS+ server identified by the DNS name. By default, no server is configured.

Step 3

Configures the TCP port for all TACACS+ requests.

Reverts to the factory default of using port 49 for server access.

Step 4

Configures the TACACS+ server identified by the specified domain name and assigns the secret key.

Step 5

Configures the timeout period for the switch to wait for a response from the specified server before it declares a timeout failure.

Setting the Global Secret Key

You can configure global values for the secret key for all TACACS+ servers.

Note If secret keys are configured for individual servers, those keys override the globally configured key.

Note You can use the dollar sign ($) and the percent sign (%) in global secret keys.

Detailed Steps

To set the secret key for TACACS+ servers, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

to indicate the encrypted format being used. If this global key and the individual server keys are not configured, clear text messages are sent to the TACACS+ server(s).

Deletes the configured global secret key to access the TACACS+ server and reverts to the factory default of allowing access to all configured servers.

Setting the Default TACACS+ Server Timeout Interval and Retransmits

By default, a switch retries a TACACS+ server only once. This number can be configured. The maximum is five retries per server. You can also configure the timeout value for the TACACS+ server.

Detailed Steps

To configure the number of retransmissions and the time between retransmissions to the TACACS+ servers, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab first).

You see the TACACS+ default settings.

Step 3 Supply values for the Timeout and Retransmits fields for authentication attempts.

icon to save the changes.

Setting the Timeout Value

You can configure a global timeout value between transmissions for all TACACS+ servers.

Note If timeout values are configured for individual servers, those values override the globally configured values.

Detailed Steps

To set the global timeout value for TACACS+ servers, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the global timeout period in seconds for the switch to wait for a response from all TACACS+ servers before the switch declares a timeout failure. The time ranges from 1 to 1440 seconds.

Deletes the configured timeout period and reverts to the factory default of 5 seconds.

Configuring a TACACS+ Server

Detailed Steps

To configure a TACACS+ server and all its options using DCNM-SAN, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab.

You see any existing TACACS+ servers.

to add a new TACACS+ server.

You see the Create TACACS+ Server dialog box as shown in Figure 4-5.

Figure 4-5 Create TACACS+ Server Dialog Box

Step 4 Select the switches that you want to assign as TACACS servers.

Step 5 Assign an index number to identify the TACACS server.

Step 6 Select the IP address type for the TACACS server.

Step 7 Fill in the IP address or name for the TACACS server.

Step 8 Modify the authentication and accounting ports used by this TACACS server.

Step 9 Select the appropriate key type for the TACACS server.

Step 10 Select the TimeOut value in seconds. The valid range is 0 to 60 seconds.

Step 11 Select the number of times the switch tries to connect to a TACACS server(s) before reverting to local authentication.

Step 12 Enter the test idle time interval value in minutes. The valid range is 1 to 1440 minutes.

Step 13 Enter the test user with the default password. The default username is test.

to save these changes.

Configuring the TACACS+ Test Idle Timer

The test idle timer specifies the interval during which a TACACS+ server receives no requests before the MDS 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.

Detailed Steps

To configure the idle timer, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the test idle time interval value in minutes. The valid range is 1 to 1440 minutes.

Step 3

Reverts to the default value (0 minutes).

Configuring Test Username

You can configure a username and password for periodic TACACS+ server status testing. You do not need to configure the user name and password to monitor TACACS+ servers. You can use the default test username (test) and default password (test).

Detailed Steps

To configure the optional username and password for periodic TACACS+ server status testing, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the test user (testuser) with the default password (test). The default username is test.

Removes the test user (testuser).

Configures the test user (testuser) and assigns a strong password.

For guidelines for creating strong passwords, see the “Characteristics of Strong Passwords” section.

Configuring the Dead Timer

The dead timer specifies the interval that the MDS switch waits, after declaring a TACACS+ server is dead, before sending out a test packet to determine if the server is now alive.

Note The default dead timer value is 0 minutes. TACACS+ server monitoring is not performed if the dead timer interval is 0 minutes, unless the TACACS+ server is a part of a bigger group with the dead-time interval greater than 0 minutes. (See “Configuring the RADIUS, TACACS+, and LDAP Server” section).

Note If the dead timer of a dead TACACS+ server expires before it is sent a TACACS+ test message, that server is marked as alive again even if it is still not responding. To avoid this scenario, configure a test user with a shorter idle time than the dead timer time.

Detailed Steps

To configure the dead timer, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the dead-time interval value in minutes. The valid range is 1 to 1440 minutes.

Reverts to the default value (0 minutes).

Note When the dead-time interval is 0 minutes, TACACS+ server monitoring is not performed unless the TACACS+ server is part of a server group and the dead-time interval for the group is greater than 0 minutes. (See the “Configuring the RADIUS, TACACS+, and LDAP Server” section).

Sending TACACS+ Test Messages for Monitoring

You can manually send test messages to monitor a TACACS+ server.

Detailed Steps

To send the test message to the TACACS+ server, follow these steps:

Command

Purpose

Sends a test message to a TACACS+ server using the default username (test) and password (test).

Sends a test message to a TACACS+ server using a configured test username and password.

A configured username and password is optional (see the “Configuring Test Username” section).

Allowing Users to Specify a TACACS+ Server at Login

Detailed Steps

To allow users logging into an MDS switch to select a TACACS+ server for authentication, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Allows users to specify a TACACS+ server to send the authentication request when logging in.

Reverts to sending the authentication request to the first server in the server group (default).

To configure the switch to allow users to specify a TACACS+ server at login using DCNM-SAN, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab.

You see the TACACS+ default settings.

check box.

icon to save the changes.

Clearing TACACS+ Server Statistics

You can clear all the TACACS+ server statistics using the clear tacacs-server statistics 10.1.2.3 command.

Configuring 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 same protocol, either RADIUS or TACACS+. The servers are tried in the same order in which you configure them.

The AAA server monitoring feature can mark an AAA server as dead. You can configure a period of time in minutes to elapse before the switch sends requests to a dead AAA server. (See the “AAA Server Monitoring” section).

Restrictions

You can configure these server groups at any time but they only take effect when you apply them to an AAA service. You configure AAA policies for CLI users or DCNM-SAN or Device Manager users.

Note Configuration of a TACACS+ group fails if MSCHPv2 authentication is not disabled.

Detailed Steps

To configure a RADIUS server group, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-radius)#

Creates a server group named RadServer and enters the RADIUS server group configuration submode for that group.

Deletes the server group called RadServer from the authentication list.

Step 3

Configures the RADIUS server at IPv4 address 10.71.58.91 to be tried first within the server group RadServer.
command and retry this command.

Step 4

Configures the RADIUS server at IPv6 address 2001:0DB8:800:200C::417A to be tried first within the server group RadServer.

Removes the RADIUS server at IPv6 address 2001:0DB8:800:200C::417A from the server group RadServer.

Step 5

Returns to configuration mode.

Step 6

switch(config-radius)#

Creates a server group named RadiusServer and enters the RADIUS server group configuration submode for that group.

Step 7

Configures ServerA to be tried first within the server group called the RadiusServer1.
command and retry this command.

Step 8

Configures ServerB to be tried second within the server group RadiusServer1.

Step 9

Configures the monitoring dead time to 30 minutes. The range is 0 through 1440.

Note If the dead-time interval for an individual RADIUS server is greater than 0, that value takes precedence over the value set for the server group.

Reverts to the default value (0 minutes).

Note If the dead-time interval for both the RADIUS server group and an individual TACACS+ server in the RADIUS server group is set to 0, the switch does not mark the RADIUS server as dead when it is found to be unresponsive by periodic monitoring. Also, the switch does not perform dead server monitoring for that RADIUS server. (See the “Configuring the RADIUS, TACACS+, and LDAP Server” section).

To configure a TACACS+ server group, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-tacacs+)#

Creates a server group named TacacsServer1 and enters the submode for that group.

Deletes the server group called TacacsServer1 from the authentication list.

Step 3

Configures ServerA to be tried first within the server group called the TacacsServer1.
command and retry this command.

Step 4

Configures ServerB to be tried second within the server group TacacsServer1.

Deletes ServerB within the TacacsServer1 list of servers.

Step 5

Configures the monitoring dead time to 30 minutes. The range is 0 through 1440.

Note If the dead-time interval for an individual TACACS+ server is greater than 0, that value takes precedence over the value set for the server group.

Reverts to the default value (0 minutes).

Note If the dead-time interval for both the TACACS+ server group and an individual TACACS+ server in the TACACS+ server group is set to 0, the switch does not mark the TACACS+ server as dead when it is found to be unresponsive by periodic monitoring. Also, the switch does not perform dead server monitoring for that TACACS+ server. (See the “Configuring a TACACS+ Server” section).

To configure a RADIUS, TACACS+, or LDAP server group using DCNM-SAN, follow these steps:

.

tab.

You see the RADIUS, TACACS+, or LDAP server groups configured.

to create a server group.

You see the Create Server dialog box.

to add a TACACS+ server group, and the ldap radio button to add a LDAP server group.

Step 4 Supply server names for the ServerIdList field.

Step 5 When you chose LDAP, enter the LDAP search map name for the LDAPSearchMapName.

- LDAPSSLMODE—Specifies if the TLS tunnel should be setup before binding with the LDAP server.

- LDAPBindFirst—Specifies if the user bind should be completed before the search.

Step 6 Click the plain radio button to select the plain authentication method, click the kerberos button to select the kerberos authentication method, and click md5digest to select the md5digest authentication method.

Step 7 Enter the password for the LDAPComparePasswd field:

- LDAPCertDNBind—Specifies if the User Certification Bind needs to be checked while doing PKI SSH certificate authorization.

- LDAPUserServerBind—Specifies if the User Server Bind should be checked as part of SSH PKI authorization.

Step 8 Set the DeadTime field for the number of minutes that a server can be nonresponsive before it is marked as bypassed. See the “About Bypassing a Nonresponsive Server” section.

to create this server group.

The LDAP Server Group displays LDAP-specific parameters.

tab to assign this server group to an application.

You can associate a server group with all applications or you can specify specific applications.

Step 11 Click the General tab to assign the type of authentication to this server group.

Check either the MSCHAP or MSCHAPv2 check box based on the type of server group.

icon to save the changes.

Once the LDAP Server group is created, the configuration information is displayed in two tabs:

- Server Groups—Displays common data shared by all AAA protocols (RADIUS, TACACS+, and LDAP).

- LDAP Server Group—Displays only LDAP-specific protocols.

Enabling AAA Server Distribution

Restrictions

Only switches where distribution is enabled can participate in the distribution activity.

Detailed Steps

To enable RADIUS server distribution, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables RADIUS configuration distribution in this switch.

Disables RADIUS configuration distribution in this switch (default).

To enable TACACS+ server distribution, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables TACACS+ configuration distribution in this switch.

Disables TACACS+ configuration distribution in this switch (default).

To enable RADIUS server distribution, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab. You see the RADIUS CFS configuration.

from the Admin drop-down list for all switches that you want to enable CFS for RADIUS.

to distribute these changes through the fabric.

.

To enable TACACS+ server distribution, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab.

You see the TACACS+ CFS configuration.

Step 3 Choose enable from the Admin drop-down list for all switches that you want to enable CFS on for TACACS+.

to distribute these changes through the fabric.

.

Committing the Distribution

The RADIUS or TACACS+ global and/or server configuration stored in the temporary buffer can be applied to the running configuration across all switches in the fabric (including the originating switch).

Detailed Steps

To commit RADIUS configuration changes, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Commits the RADIUS configuration changes to the running configuration.

To commit TACACS+ configuration changes, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Commits the TACACS+ configuration changes to the running configuration.

To distribute a RADIUS or TACACS+ configuration, follow these steps:

. You see the RADIUS or TACACS+ configuration in the Information pane.

tab. You see the RADIUS or TACACS+ CFS configuration.

in the Config Action drop-down list for all switches that you want to enable CFS for RADIUS or TACACS+.

to distribute the changes through the fabric.

.

Discarding the Distribution Session

Discarding the distribution of a session in progress causes the configuration in the temporary buffer to be dropped. The distribution is not applied.

Detailed Steps

To discard the RADIUS sessionin-progress distribution, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Discards the RADIUS configuration changes to the running configuration.

To discard the TACACS+ sessionin-progress distribution, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Discards the TACACS+ configuration changes to the running configuration.

To discard RADIUS or TACACS+ distribution, follow these steps:

. You see either the RADIUS or TACACS+ configuration in the Information pane.

tab. You see either the RADIUS or TACACS+ CFS configuration.

from the Config Action drop-down list for each switch that should discard the pending RADIUS or TACACS+ distribution.

.

.

Clearing Sessions

Detailed Steps

command from any switch in the fabric.

switch# clear radius session

command from any switch in the fabric.

switch# clear tacacs+ session

To clear a RADIUS or TACACS+ distribution, follow these steps:

.

You see either the RADIUS or TACACS+ configuration in the Information pane.

tab. You see either the RADIUS or TACACS+ CFS configuration.

from the Config Action drop-down list for each switch that should clear the pending RADIUS or TACACS+ distribution.

.

.

Enabling CHAP Authentication

Detailed Steps

To enable CHAP authentication, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables CHAP login authentication.

Disables CHAP login authentication.

Enabling MSCHAP Authentication

Detailed Steps

To enable MSCHAP authentication, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables MSCHAP login authentication.

Step 3

Disables MSCHAP login authentication.

To enable MSCHAPv2 authentication, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables MSCHAPv2 login authentication.

Step 3

Disables MSCHAPv2 login authentication.

Note Password aging, MSCHAPv2, and MSCHAP authentication can fail if one of these authentication is not disabled.

Note A warning message is issued when you execute a command to enable MSCHAPv2 authentication on the TACACS+ server, and the configuration fails.

To enable MSCHAP authentication using Device Manager, follow these steps:

.

You see the AAA configuration in the Information pane (see Figure 4-6).

Figure 4-6 AAA Configuration in Device Manager

tab.

You see the MSCHAP configuration (see Figure 4-7).

Figure 4-7 MSCHAP Configuration

check box to use MSCHAP or MSCHAPv2 to authenticate users on the switch.

to save the changes.

.

Configuring Cisco Access Control Servers

The Cisco Access Control Server (ACS) uses TACACS+ and RADIUS protocols to provide AAA services that ensure a secure environment. When using the AAA server, user management is normally done using Cisco ACS. Figure 4-8, Figure 4-9, Figure 4-10, and Figure 4-11 display ACS server user setup configurations for network-admin roles and multiple roles using either RADIUS or TACACS+.

Figure 4-8 Configuring the network-admin Role When Using RADIUS

Figure 4-9 Configuring Multiple Roles with SNMPv3 Attributes When Using RADIUS

Figure 4-10 Configuring the network-admin Role with SNMPv3 Attributes When Using TACACS+

Figure 4-11 Configuring Multiple Roles with SNMPv3 Attributes When Using TACACS+

Verifying RADIUS and TACACS+ Configuration

To display the RADIUS and TACACS+ configuration information, perform one of the following tasks:

Command

Purpose

Displays aaa Authorization Information Details.

Displays Default User Role for Remote Authentication

show radius-server directed-request

Display the RADIUS directed request configuration.

show tacacs-server directed-request

Display the TACACS+ directed request configuration.

show radius-server groups

Verify the configured server group order.

show aaa authentication login chap

Display the CHAP authentication configuration.

show aaa authentication login mschap

Display the MSCHAP authentication configuration.

show aaa authentication login mschapv2

Display the MSCHAPv2 authentication configuration.

show radius-server

Displays Configured RADIUS Information.

show radius-server groups

Displays Configured RADIUS Server-Group Order.

show radius-server statistics 10.1.3.2

Displays RADIUS Server Statistics.

show tacacs-server

Displays Configured TACACS+ Server Information.

show aaa authentication

Displays AAA Authentication Information.

show aaa authentication login error-enable

Displays AAA Authentication Login Information.

show tacacs-server groups

Displays Configured TACACS+ Server Groups.

show aaa groups

Displays All AAA Server Groups.

show tacacs-server statistics 10.1.2.3

Displays TACACS+ Server Statistics.

show radius distribution status

Displays the distribution status on the CFS tab.

show tacacs+ distribution status

Displays the session status once the implicit distribution session has started.

show radius pending-diff

Displays the RADIUS or TACACS+ global and/or server configuration stored in the temporary buffer.

show tacacs+ pending-diff

Displays the TACACS+ global and/or server configuration stored in the temporary buffer.

show radius distribution status

Displays the RADIUS Fabric Merge Status.

show tacacs+ distribution status

Displays the TACACS+ Fabric Merge Status.

show accounting log

Displays the Accounting Log Information.

show aaa authentication

Displays Authentication Information.

show accounting config

Displays Two Samples of Configured Accounting Parameters.

show accounting log 60000

Displays 60,000 Bytes of the Accounting Log.

show accounting log

Displays the Entire Log File.

.

- Displaying RADIUS Server Statistics

- Displaying RADIUS Server Details

- Displaying RADIUS Server Statistics

- Displaying TACACS+ Server Statistics

- Displaying TACACS+ Server Details

- Displaying the Session Status

- Displaying the Pending Configuration to be Distributed

- Displaying AAA Authentication

- Displaying Accounting Configuration

Displaying RADIUS Server Statistics

To display RADIUS server statistics, follow these steps:

.

You see the RADIUS configuration in the Information pane.

tab.

You see the RADIUS server statistics.

Displaying RADIUS Server Details

command to display configured RADIUS parameters as shown in Example 4-2.

Example 4-2 Displays Configured RADIUS Information

switch# show radius-server

Global RADIUS shared secret:*******

retransmission count:5

timeout value:10

following RADIUS servers are configured:

myradius.cisco.users.com:

available for authentication on port:1812

available for accounting on port:1813

172.22.91.37:

available for authentication on port:1812

available for accounting on port:1813

RADIUS shared secret:******

10.10.0.0:

available for authentication on port:1812

available for accounting on port:1813

RADIUS shared secret:******

Example 4-3 Displays Configured RADIUS Server-Group Order

switch# show radius-server groups

total number of groups:4

following RADIUS server groups are configured:

group radius:

server: all configured radius servers

group Group1:

server: Server3 on auth-port 1812, acct-port 1813

server: Server5 on auth-port 1812, acct-port 1813

group Group5:

Displaying RADIUS Server Statistics

command.

Example 4-4 Displays RADIUS Server Statistics

switch# show radius-server statistics 10.1.3.2

Server is not monitored

Authentication Statistics

failed transactions: 0

sucessfull transactions: 0

requests sent: 0

requests timed out: 0

responses with no matching requests: 0

responses not processed: 0

responses containing errors: 0

Accounting Statistics

failed transactions: 0

sucessfull transactions: 0

requests sent: 0

requests timed out: 0

responses with no matching requests: 0

responses not processed: 0

responses containing errors:

You can clear RADIUS server statistics using the clear radius-server statistics 10.1.3.2 command.

Displaying TACACS+ Server Statistics

To display TACACS+ server statistics, follow these steps:

.

You see the TACACS+ configuration in the Information pane.

tab.

You see the TACACS+ server statistics.

Displaying TACACS+ Server Details

.

Example 4-5 Displays Configured TACACS+ Server Information

switch# show tacacs-server

Global TACACS+ shared secret:***********

timeout value:30

total number of servers:3

following TACACS+ servers are configured:

171.71.58.91:

available on port:2

cisco.com:

available on port:49

171.71.22.95:

available on port:49

TACACS+ shared secret:*****

Example 4-6 Displays AAA Authentication Information

switch# show aaa authentication

default: group TacServer local none

console: local

iscsi: local

dhchap: local

Example 4-7 Displays AAA Authentication Login Information

switch# show aaa authentication login error-enable

enabled

switch# show tacacs-server groups

total number of groups:2

following TACACS+ server groups are configured:

group TacServer:

server 171.71.58.91 on port 2

group TacacsServer1:

server ServerA on port 49

server ServerB on port 49:

Example 4-9 Displays All AAA Server Groups

switch# show aaa groups

radius

TacServer

Example 4-10 Displays TACACS+ Server Statistics

switch# show tacacs-server statistics 10.1.2.3

Server is not monitored

Authentication Statistics

failed transactions: 0

sucessfull transactions: 0

requests sent: 0

requests timed out: 0

responses with no matching requests: 0

responses not processed: 0

responses containing errors: 0

Authorization Statistics

failed transactions: 0

sucessfull transactions: 0

requests sent: 0

requests timed out: 0

responses with no matching requests: 0

responses not processed: 0

responses containing errors: 0

Accounting Statistics

failed transactions: 0

sucessfull transactions: 0

requests sent: 0

requests timed out: 0

responses with no matching requests: 0

responses not processed: 0

responses containing errors: 0

Displaying the Session Status

Once the implicit distribution session has started, you can check the session status from DCNM-SAN by expanding Switches > Security > AAA, and selecting RADIUS or TACACS+.

on the CFS tab.

switch# show radius distribution status

distribution : enabled

session ongoing: yes

session owner: admin

session db: exists

merge protocol status: merge activation done

last operation: enable

last operation status: success

command.

switch# show tacacs+ distribution status

distribution : enabled

session ongoing: yes

session owner: admin

session db: exists

merge protocol status: merge activation done

last operation: enable

last operation status: success

Displaying the Pending Configuration to be Distributed

command, follow these steps:

switch(config)# show radius pending-diff

+radius-server host testhost1 authentication accounting

+radius-server host testhost2 authentication accounting

command.

switch(config)# show tacacs+ pending-diff

+tacacs-server host testhost3

+tacacs-server host testhost4

To display the RADIUS or TACACS+ global and/or server configuration stored in the temporary buffer, follow these steps:

.

Step 2 Click the CFS tab.

You see the distribution status on the CFS tab.

radio button.

to save the changes.

tab to view the pending or running configuration.

command to view the status of the RADIUS fabric merge as shown in Example 4-11.

Example 4-11 Displays the RADIUS Fabric Merge Status

switch# show radius distribution status

distribution : enabled

session ongoing: no

session db: does not exist

merge protocol status: merge response received

merge error: conflict: server dmtest2 has auth-port 1812 on this switch and 1999

on remote

last operation: enable

last operation status: success

command to view the status of the TACACS+ fabric merge as shown in Example 4-12.

Example 4-12 Displays the TACACS+ Fabric Merge Status

switch# show tacacs+ distribution status

distribution : enabled

session ongoing: no

session db: does not exist

merge protocol status: merge activation done

last operation: enable

last operation status: success

command to configure local users and their roles.

command to view the local accounting log as shown in Example 4-13.

Example 4-13 Displays the Accounting Log Information

switch# show accounting log

Thu Dec 10 06:19:21 2009:type=update:id=console0:user=root:cmd=enabled telnet

Thu Dec 10 06:19:21 2009:type=update:id=console0:user=root:cmd=configure termina

l ; feature telnet (SUCCESS)

Thu Dec 10 06:19:35 2009:type=start:id=171.69.16.56@pts/1:user=admin:cmd=

Thu Dec 10 06:20:16 2009:type=stop:id=171.69.16.56@pts/1:user=admin:cmd=shell te

rminated gracefully

Thu Dec 10 06:20:20 2009:type=stop:id=console0:user=root:cmd=shell terminated gr

acefully

Thu Dec 10 06:29:37 2009:type=start:id=72.163.177.168@pts/1:user=admin:cmd=

Thu Dec 10 06:29:42 2009:type=update:id=72.163.177.168@pts/1:user=admin:cmd=pwd

(SUCCESS)

Thu Dec 10 06:32:49 2009:type=start:id=72.163.190.8@pts/2:user=admin:cmd=

Displaying AAA Authentication

command displays the configured authentication methods as shown in Example 4-14.

Example 4-14 Displays Authentication Information

switch# show aaa authentication

No AAA Authentication

default: group TacServer local none

console: local none

iscsi: local

dhchap: local

Displaying Accounting Configuration

command. By default approximately 250 KB of the accounting log is displayed.

Example 4-15 Displays Two Samples of Configured Accounting Parameters

switch# show accounting config

show aaa accounting

default: local

switch# show aaa accounting

default: group rad1

Example 4-16 Displays 60,000 Bytes of the Accounting Log

switch# show accounting log 60000

Fri Jan 16 15:28:21 1981:stop:snmp_348506901_64.104.131.208:admin:

Fri Jan 16 21:17:04 1981:start:/dev/pts/0_348527824:admin:

Fri Jan 16 21:35:45 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

Fri Jan 16 21:35:51 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

Fri Jan 16 21:35:51 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group5

Fri Jan 16 21:35:55 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group5

Fri Jan 16 21:35:55 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group3

Fri Jan 16 21:58:17 1981:start:snmp_348530297_171.71.150.105:admin:

...

Example 4-17 Displays the Entire Log File

switch# show accounting log

Fri Jan 16 15:28:21 1981:stop:snmp_348506901_64.104.131.208:admin:

Fri Jan 16 21:17:04 1981:start:/dev/pts/0_348527824:admin:

Fri Jan 16 21:35:45 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

Fri Jan 16 21:35:51 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

Fri Jan 16 21:35:51 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group5

Fri Jan 16 21:35:55 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group5

Fri Jan 16 21:35:55 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group3

Fri Jan 16 21:58:17 1981:start:snmp_348530297_171.71.150.105:admin:

Fri Jan 16 21:58:17 1981:stop:snmp_348530297_171.71.150.105:admin:

Fri Jan 16 21:58:18 1981:start:snmp_348530298_171.71.150.105:admin:

Fri Jan 16 21:58:18 1981:stop:snmp_348530298_171.71.150.105:admin:

...

Fri Jan 16 23:37:02 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group3

Fri Jan 16 23:37:26 1981:update:/dev/pts/0_348527824:admin:updated TACACS+ parameters for group:TacacsServer1

Fri Jan 16 23:45:19 1981:update:/dev/pts/0_348527824:admin:updated TACACS+ parameters for group:TacacsServer1

Fri Jan 16 23:45:19 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

...

Fri Jan 16 23:53:51 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for server:Server3

Fri Jan 16 23:54:00 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for server:Server5

Fri Jan 16 23:54:22 1981:update:/dev/pts/0_348527824:admin:updated TACACS+ parameters for server:ServerA

Fri Jan 16 23:54:25 1981:update:/dev/pts/0_348527824:admin:updated TACACS+ parameters for server:ServerB

Fri Jan 16 23:55:03 1981:update:/dev/pts/0_348527824:admin:updated RADIUS parameters for group:Group1

...

Sat Jan 17 00:01:41 1981:start:snmp_348537701_171.71.58.100:admin:

Sat Jan 17 00:01:41 1981:stop:snmp_348537701_171.71.58.100:admin:

Sat Jan 17 00:01:42 1981:start:snmp_348537702_171.71.58.100:admin:

Sat Jan 17 00:01:42 1981:stop:snmp_348537702_171.71.58.100:admin:

...

Monitoring RADIUS and TACACS+

This section includes the following topics:

- Verifying Authorization Profile

- Testing Authorization

Verifying Authorization Profile

You can verify the authorizaion profile for different commands. When enabled, all commands are directed to the Access Control Server (ACS) for verification. The verification details are displayed once the verification is completed.

switch# terminal verify-only username Moheed

switch# config terminal

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

switch(config)# feature telnet

% Success

switch(config)# feature ssh

% Success

switch(config)# end

% Success

switch# exit

Note This command only verifies the commands and does not enable the configuration.

Testing Authorization

You can test the authorization settings for any command.

To test the authorization of a command, use the test aaa authorization command-type command.

switch(config)# test aaa authorization command-type commands user u1 command "feature dhcp"

% Success

Configuration Examples for LDAP

The following example shows how to configure an LDAP server host and server group:

feature ldap

ldap-server host 10.10.2.2 enable-ssl

aaa group server ldap LdapServer

server 10.10.2.2

exit

show ldap-server

show ldap-server groups

The following example shows how to configure an LDAP search map:

ldap search-map s0

userprofile attribute-name description search-filter (&(objectClass=inetOrgPerson)(cn=$userid)) base-DN dc=acme,dc=com

exit

show ldap-search-map

The following example shows how to configure AAA authorization with certificate authentication for an LDAP server:

aaa authorization ssh-certificate default group LDAPServer1 LDAPServer2

exit

show aaa authorization

Feature History for RADIUS, TACACS+, and LDAP

lists the release history for this feature. Only features that were introduced or modified in Cisco NX-OS Release 5.x or a later release appear in the table.

Table 4-6 Feature History for RADIUS, TACACS+, and LDAP

Feature Name

Releases

Feature Information

Configuring LDAP

5.2

Added LDAP server and server groups configuration.

Switch AAA Functionalities

5.0(1a)

Added configuring fallback mechanism for authentication, configuring AAA server monitoring parameters globally.

Configuring TACACS+ Server Monitoring Parameters

5.0(1a)

Added CHAP authentication.

OTP Authentication

5.0(1a)

Added one-time password support

Merge Guidelines for RADIUS and TACACS+ Configurations

5.0(1a)

TACACS test parameters have to be distributed via CFS; a note has been changed.

AAA Service Configuration Options

5.0(1a)

Note has been changed.

Configuring IPv4 and IPv6 Access Control Lists

Cisco MDS 9000 Family switches can route IP version 4 (IPv4) traffic between Ethernet and Fibre Channel interfaces. The IP static routing feature routes traffic between VSANs. To do so, each VSAN must be in a different IPv4 subnetwork. Each Cisco MDS 9000 Family switch provides the following services for network management systems (NMS):

- IP forwarding on the out-of-band Ethernet interface (mgmt0) on the front panel of the supervisor modules.

- IP forwarding on the in-band Fibre Channel interface using the IP over Fibre Channel (IPFC) function—IPFC specifies how IP frames can be transported over Fibre Channel using encapsulation techniques. IP frames are encapsulated into Fibre Channel frames so NMS information can cross the Fibre Channel network without using an overlay Ethernet network.

- IP routing (default routing and static routing)—If your configuration does not need an external router, you can configure a default route using static routing.

Switches are compliant with RFC 2338 standards for Virtual Router Redundancy Protocol (VRRP) features. VRRP is a restartable application that provides a redundant, alternate path to the gateway switch.

IPv4 Access Control Lists (IPv4-ACLs and IPv6-ACLs) provide basic network security to all switches in the Cisco MDS 9000 Family. IPv4-ACLs and IPv6-ACLs restrict IP-related traffic based on the configured IP filters. A filter contains the rules to match an IP packet, and if the packet matches, the rule also stipulates if the packet should be permitted or denied.

Each switch in the Cisco MDS 9000 Family can have a maximum total of 128 IPv4-ACLs or 128 IPv6-ACLs and each IPv4-ACL or IPv6-ACL can have a maximum of 256 filters.

This chapter includes the following topics:

- Information About IPv4 and IPv6 Access Control Lists

- Guidelines and Limitations

- Configuring IPv4-ACLs or IPv6-ACLs

- Verifying the IPv4 or IPv6 Configuration

- Configuration Examples for IP-ACL

- Field Descriptions for IPv4 and IPv6 Access Control Lists

Information About IPv4 and IPv6 Access Control Lists

Cisco MDS 9000 Family switches can route IP version 4 (IPv4) traffic between Ethernet and Fibre Channel interfaces. The IP static routing feature routes traffic between VSANs. To do so, each VSAN must be in a different IPv4 subnetwork. Each Cisco MDS 9000 Family switch provides the following services for network management systems (NMS):

- IP forwarding on the out-of-band Ethernet interface (mgmt0) on the front panel of the supervisor modules.

- IP forwarding on the in-band Fibre Channel interface using the IP over Fibre Channel (IPFC) function—IPFC specifies how IP frames can be transported over Fibre Channel using encapsulation techniques. IP frames are encapsulated into Fibre Channel frames so NMS information can cross the Fibre Channel network without using an overlay Ethernet network.

- IP routing (default routing and static routing)—If your configuration does not need an external router, you can configure a default route using static routing.

IPv4 Access Control Lists (IPv4-ACLs and IPv6-ACLs) provide basic network security to all switches in the Cisco MDS 9000 Family. IPv4-ACLs and IPv6-ACLs restrict IP-related traffic based on the configured IP filters. A filter contains the rules to match an IP packet, and if the packet matches, the rule also stipulates if the packet should be permitted or denied.

Each switch in the Cisco MDS 9000 Family can have a maximum total of 128 IPv4-ACLs or 128 IPv6-ACLs and each IPv4-ACL or IPv6-ACL can have a maximum of 256 filters.

This section contains the following topics:

- About Filter Contents

- Protocol Information

- Address Information

- Port Information

- ICMP Information

- ToS Information

About Filter Contents

An IP filter contains rules for matching an IP packet based on the protocol, address, port, ICMP type, and type of service (ToS).

Protocol Information

The protocol information is required in each filter. It identifies the name or number of an IP protocol. You can specify the IP protocol in one of two ways:

- Specify an integer ranging from 0 to 255. This number represents the IP protocol.

- Specify the name of a protocol including, but not restricted to, Internet Protocol (IP ), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Control Message Protocol (ICMP).

Note When configuring IPv4-ACLs or IPv6-ACLs on Gigabit Ethernet interfaces, only use the TCP or ICMP options.

Address Information

The address information is required in each filter. It identifies the following details:

- Source—The address of the network or host from which the packet is being sent.

- Source-wildcard—The wildcard bits applied to the source.

- Destination—The number of the network or host to which the packet is being sent.

- Destination-wildcard—The wildcard bits applied to the destination.

Specify the source and source-wildcard or the destination and destination-wildcard in one of two ways:

- Using the 32-bit quantity in four-part, dotted decimal format (10.1.1.2/0.0.0.0 is the same as host 10.1.1.2).

– Each wildcard bit set to zero indicates that the corresponding bit position in the packet's IPv4 address must exactly match the bit value in the corresponding bit position in the source.

– Each wildcard bit set to one indicates that both a zero bit and a one bit in the corresponding position of the packet's IPv4 or IPv6 address will be considered a match to this access list entry. Place ones in the bit positions you want to ignore. For example, 0.0.255.255 requires an exact match of only the first 16 bits of the source. Wildcard bits set to one do not need to be contiguous in the source-wildcard. For example, a source-wildcard of 0.255.0.64 would be valid.

- Using the any option as an abbreviation for a source and source-wildcard or destination and destination-wildcard (0.0.0.0/255.255.255.255)

Port Information

(range of ports) option. You can specify the port information in one of two ways:

- Specify the number of the port. Port numbers range from 0 to 65535. Table 5-1 displays the port numbers recognized by the Cisco NX-OS software for associated TCP and UDP ports.

- Specify the name of a TCP or UDP port as follows:

– TCP port names can only be used when filtering TCP.

– UDP port names can only be used when filtering UDP.

Table 5-1 TCP and UDP Port Numbers

Protocol

Port

Number

UDP

dns

53

tftp

69

ntp

123

radius accounting

1646 or 1813

radius authentication

1645 or 1812

snmp

161

snmp-trap

162

syslog

514

TCP1

ftp

20

ftp-data

21

ssh

22

telnet

23

smtp

25

tasacs-ds

65

www

80

sftp

115

http

143

wbem-http

5988

wbem-https

5989

1.If the TCP connection is already established, use the established option to find matches. A match occurs if the TCP datagram has the ACK, FIN, PSH, RST, or URG control bit set.

1.If the TCP connection is already established, use the established option to find matches. A match occurs if the TCP datagram has the ACK, FIN, PSH, RST, or URG control bit set.

ICMP Information

IP packets can be filtered based on the following optional ICMP conditions:

- icmp-type—The ICMP message type is a number from 0 to 255.

- icmp-code—The ICMP message code is a number from 0 to 255.

displays the value for each ICMP type.

Table 5-2 ICMP Type Value

ICMP Type 2

Code

echo

8

echo-reply

0

destination unreachable

3

traceroute

30

time exceeded

11

2.ICMP redirect packets are always rejected.

2.ICMP redirect packets are always rejected.

ToS Information

IP packets can be filtered based on the following optional ToS conditions:

- ToS level—The level is specified by a number from 0 to 15.

- ToS name—The name can be max-reliability, max-throughput, min-delay, min-monetary-cost, and normal.

Guidelines and Limitations

Follow these guidelines when configuring IPv4-ACLs or IPv6-ACLs in any switch or director in the Cisco MDS 9000 Family:

- You can apply IPv4-ACLs or IPv6-ACLs to VSAN interfaces, the management interface, Gigabit Ethernet interfaces on IPS modules and MPS-14/2 modules, and Ethernet PortChannel interfaces.

Tip If IPv4-ACLs or IPv6-ACLs are already configured in a Gigabit Ethernet interface, you cannot add this interface to an Ethernet PortChannel group. See the Cisco MDS 9000 Family NX-OS IP Services Configuration GuideIP Services Configuration Guide, Cisco DCNM for SAN for guidelines on configuring IPv4-ACLs.

Caution Do not apply IPv4-ACLs or IPv6-ACLs to only one member of a PortChannel group. Apply IPv4-ACLs or IPv6-ACLs to the entire channel group.

- Configure the order of conditions accurately. As the IPv4-ACL or the IPv6-ACL filters are sequentially applied to the IP flows, only the first match determines the action taken. Subsequent matches are not considered. Be sure to configure the most important condition first. If no conditions match, the software drops the packet.

- Configure explicit deny on the IP Storage Gigabit Ethernet ports to apply IP ACLs because implicit deny does not take effect on these ports.

Configuring IPv4-ACLs or IPv6-ACLs

This section contains the following topics:

- Creating IPv4-ACLs or IPv6-ACLs

- “Adding IP Filters to an Existing IPv4-ACL or IPv6-ACL” section

- Removing IP Filters from an Existing IPv4-ACL or IPv6-ACL

- Deleting IP-ACLs

- Reading the IP-ACL Log Dump

- Applying an IP-ACL to an Interface

- Applying an IP-ACL to mgmt0

Creating IPv4-ACLs or IPv6-ACLs with the IP-ACL Wizard

for traffic that is not permitted. A single-entry IPv4-ACL or IPv6-ACL with only one deny entry has the effect of denying all traffic.

Detailed Steps

To configure an IPv4-ACL or an IPv6-ACL, follow these steps:

Step 1 Create an IPv4-ACL or an IPv6-ACL by specifying a filter name and one or more access condition(s). Filters require the source and destination address to match a condition. Use optional keywords to configure finer granularity.

Note The filter entries are executed in sequential order. You can only add the entries to the end of the list. Take care to add the entries in the correct order.

Step 2 Apply the access filter to specified interfaces.

To create an ordered list of IP filters in a named IPv4-ACL or IPv6-ACL profile using the IPv4-ACL Wizard, follow these steps:

Detailed Steps

icon from the DCNM-SAN toolbar (see Figure 5-1).

Figure 5-1 IP ACL Wizard

You see the IP ACL Wizard.

Step 2 Enter a name for the IP-ACL.

Note If you are creating an IPv6-ACL, check the IPv6 check box.

to add a new rule to this IP-ACL. You see a new rule in the table with default values.

Step 4 Modify the Source IP and Source Mask as necessary for your filter.

Note The IP-ACL Wizard only creates inbound IP filters.

Step 5 Choose the appropriate filter type from the Application drop-down list.

from the Action drop-down list.

Step 7 Repeat Step 3 through Step 6 for additional IP filters.

to order the filters in this IP-ACL.

Tip Order the IP filters carefully. Traffic is compared to the IP filters in order. The first match is applied and the rest are ignored.

.

You see a list of switches that you can apply this IP-ACL.

Step 10 Uncheck any switches that you do not want to apply this IP-ACL.

you want to apply this IP-ACL.

to create this IP-ACL and apply it to the selected switches.

Creating IPv4-ACLs or IPv6-ACLs

Detailed Steps

To create an IPv4-ACL, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures an IPv4-ACL called List1 and permits IP traffic from any source address to any destination address.

Removes the IPv4-ACL called List1.

Step 3

Updates List1 to deny TCP traffic from any source address to any destination address.

To create an IPv6-ACL, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ipv6-acl)#

Configures an IPv6-ACL called List1 and enters IPv6-ACL configuration submode.

Removes the IPv6-ACL called List1 and all its entries.

Step 3

Adds an entry permitting IPv6 traffic from any source address to any destination address.

Removes an entry from the IPv6-ACL.

Adds an entry to deny TCP traffic from any source address to any destination address.

To define an IPv4-ACL that restricts management access, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Defines an entry in an IPv4-ACL named restrict_mgmt allowing all addresses in the 10.67.16.0/24 subnet.

Step 3

Adds an entry to an IPv4-ACL named restrict_mgmt to allow any device to ping the MDS (icmp type 8).

Step 4

Explicitly blocks all other access to an access-list named restrict_mgmt.

To define an IPv6-ACL that restricts management access, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-ipv6-acl)#

Configures an IPv6-ACL called RestrictMgmt and enters IPv6-ACL configuration submode.

Step 3

Defines an entry allowing all addresses in the 2001:0DB8:800:200C::/64 prefix.

Step 4

Adds an entry to allow any device to ping the MDS (ICMP type 8).

Step 5

Explicitly blocks all other IPv6 access.

To use the operand and port options for an IPv4-ACL, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Denies TCP traffic from 1.2.3.0 through source port 5 to any destination.

To use the operand and port options for an IPv6-ACL, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Denies TCP traffic from 2001:0DB8:800:200C::/64 through source port 5 to any destination.

To add entries to an existing IPv4-ACL or an IPv6-ACL using Device Manager, follow these steps:

.

to create an IP-ACL profile.

You see the Create IP ACL Profiles dialog box. Enter an IP-ACL profile name.

.

This creates a new IP-ACL profile.

.

After you create an IPv4-ACL or an IPv6-ACL, you can add subsequent IP filters at the end of the IPv4-ACL or the IPv6-ACL if you are using Device Manager. DCNM-SAN allows you to reorder existing rules for a profile. You cannot insert filters in the middle of an IPv4-ACL or an IPv6-ACL. Each configured entry is automatically added to the end of a IPv4-ACL or an IPv6-ACL.

to create an IP filter.

for the Action and set the IP Number in the Protocol field. The drop-down menu provides common filtered protocols.

check box to match this filter against any IP address.

This creates an IP filter that will check the source IP address of frames.

Note The wildcard mask denotes a subset of the IP address you want to match against. This allows a range of addresses to match against this filter.

Step 8 Set the transport layer source port range if the protocol chosen is TCP or UDP.

Step 9 Repeat Step 7 and Step 8 for the destination IP address and port range.

This creates an IP filter that will check the destination IP address of frames.

Step 10 Set the ToS, ICMPType, and ICMPCode fields as appropriate.

check box if you want to match TCP connections with ACK,FIN,PSH,RST,SYN or URG control bits set.

check box if you want to log all frames that match this IP filter.

to create this IP filter and add it to your IP-ACL.

Adding IP Filters to an Existing IPv4-ACL or IPv6-ACL

After you create an IPv4-ACL or an IPv6-ACL, you can add subsequent IP filters at the end of the IPv4-ACL or the IPv6-ACL. You cannot insert filters in the middle of an IPv4-ACL or an IPv6-ACL. Each configured entry is automatically added to the end of a IPv4-ACL or a IPv6-ACL.

Detailed Steps

To add entries to an existing IPv4-ACL, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Permits TCP for Telnet traffic.

Step 3

Permits TCP for HTTP traffic.

Step 4

Permits UDP for all traffic.

To add entries to an existing IPv6-ACL, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ipv6-acl)#

Configures an IPv6-ACL and enters IPv6-ACL configuration submode.

Step 3

Permits TCP for Telnet traffic.

Step 4

Permits TCP for HTTP traffic.

Step 5

Permits UDP for all traffic.

Removing IP Filters from an Existing IPv4-ACL or IPv6-ACL

Detailed Steps

To remove configured entries from an IPv4-ACL, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Removes this entry from the IPv4-ACL (List2).

Removes this entry from the IPv4-ACL (x3).

Removes this entry from the IPv4-ACL (x3).

To remove configured entries from an IPv6-ACL, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ipv6-acl)#

Configures an IPv6-ACL and enters IPv6-ACL configuration submode.

Step 3

Removes the TCP entry from the IPv6-ACL.

Step 4

Removes the IP entry from the IPv6-ACL.

To remove configured entries from an IPv4-ACL or an IPv6-ACL using Device Manager, follow these steps:

.

You see the IP-ACL dialog box.

.

You see the list of IP filters associated with this IP-ACL.

to delete that IP filter.

Deleting IP-ACLs

Prerequisites

You must delete the association between the IP-ACL and interfaces before deleting the IP-ACL.

Detailed Steps

To delete an IP-ACL, follow these steps:

from the Physical Attributes pane.

You see the IP-ACL configuration in the Information pane.

tab.

You see a list of switches, ACLs, and profile names.

Step 3 Select the row you want to delete. To delete multiple rows, hold down the Shift key while selecting rows.

. The IP-ACLs are deleted.

Reading the IP-ACL Log Dump

Use the LogEnabled check box option during IP filter creation to log information about packets that match this filter. The log output displays the ACL number, permit or deny status, and port information.

option at the end of a filter condition to log information about packets that match dropped entries. The log output displays the ACL number, permit or deny status, and port information.

Note To capture these messages in a logging destination, you must configure severity level 7 for the kernel and ipacl facilities and severity level 7 for the logging destination: logfile, monitor or console. For example:

switch# config t

switch(config)# logging level kernel 7

switch(config)# logging level ipacl 7

switch(config)# logging logfile message 7

For the input ACL, the log displays the raw MAC information. The keyword “MAC=” does not refer to showing an Ethernet MAC frame with MAC address information. It refers to the Layer 2 MAC-layer information dumped to the log. For the output ACL, the raw Layer 2 information is not logged.

The following example is an input ACL log dump:

Jul 17 20:38:44 excal-2

%KERN-7-SYSTEM_MSG:

%IPACL-7-DENY:IN=vsan1 OUT= MAC=10:00:00:05:30:00:47:df:10:00:00:05:30:00:8a:1f:aa:aa:03:00:00:00:08:00:45:00:00:54:00:00:40:00:40:01:0e:86:0b:0b:0b:0c:0b:0b:0b:02:08:00:ff:9c:01:15:05:00:6f:09:17:3f:80:02:01:00:08:09:0a:0b:0c:0d:0e:0f:10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f:20:21:22:23:24:25:26:27:28:29:2a:2b SRC=11.11.11.12 DST=11.11.11.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=277 SEQ=1280

The following example is an output ACL log dump:

Jul 17 20:38:44 excal-2

%KERN-7-SYSTEM_MSG:

%IPACL-7-DENY:IN= OUT=vsan1 SRC=11.11.11.2 DST=11.11.11.12 LEN=84 TOS=0x00 PREC=0x00 TTL=255 ID=38095 PROTO=ICMP TYPE=0 CODE=0 ID=277 SEQ=1280

Applying an IP-ACL to an Interface

You can define IP-ACLs without applying them. However, the IP-ACLs will have no effect until they are applied to an interface on the switch. You can apply IP-ACLs to VSAN interfaces, the management interface, Gigabit Ethernet interfaces on IPS modules and MPS-14/2 modules, and Ethernet PortChannel interfaces.

Tip Apply the IP-ACL on the interface closest to the source of the traffic.

When you are trying to block traffic from source to destination, you can apply an inbound IPv4-ACL to M0 on Switch 1 instead of an outbound filter to M1 on Switch 3 (see Figure 5-2).

Figure 5-2 Denying Traffic on the Inbound Interface

option controls access to an interface. Each interface can only be associated with one IP-ACL per direction. The ingress direction can have a different IP-ACL than the egress direction. The IP-ACL becomes active when applied to the interface.

Tip Create all conditions in an IP-ACL before applying it to the interface.

Caution If you apply an IP-ACL to an interface before creating it, all packets in that interface are dropped because the IP-ACL is empty.

are used as referenced by the switch:

- In—Traffic that arrives at the interface and goes through the switch; the source is where it transmitted from and the destination is where it is transmitted to (on the other side of the router).

Tip The IP-ACL applied to the interface for the ingress traffic affects both local and remote traffic.

- Out—Traffic that has already been through the switch and is leaving the interface; the source is where it transmitted from and the destination is where it is transmitted to.

Tip The IP-ACL applied to the interface for the egress traffic only affects local traffic.

Detailed Steps

To apply an IPv4-ACL to an interface, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-if)#

Configures a management interface (mgmt0).

Step 3

Applies an IPv4-ACL called restrict_mgmt for both the ingress and egress traffic (default).

Removes the IPv4-ACL called NotRequired.

Step 4

Applies an IPv4-ACL called restrict_mgmt (if it does not already exist) for ingress traffic.

Removes the IPv4-ACL called restrict_mgmt for ingress traffic.

Applies an IPv4-ACL called SampleName2 (if it does not already exist) for local egress traffic.

Removes the IPv4-ACL called SampleName2 for local egress traffic.

To apply an IPv6-ACL to an interface, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-if)#

Configures a management interface (mgmt0).

Step 3

Applies an IPv6-ACL called RestrictMgmt (if it does not already exist) for ingress traffic.

Removes the IPv6-ACL called RestrictMgmt for ingress traffic.

Applies an IPv6-ACL called SampleName2 (if it does not already exist) for local egress traffic.

Removes the IPv6-ACL called SampleName2 for local egress traffic.

Applying an IP-ACL to mgmt0

A system default ACL called mgmt0 exists on the mgmt0 interface. This ACL is not visible to the user, so mgmt0 is a reserved ACL name that cannot be used. The mgmt0 ACL blocks most ports and only allows access to required ports in compliance to accepted security policies.

Detailed Steps

To apply an IP-ACL to an interface, follow these steps:

in the Physical Attributes pane.

You see the IP-ACL configuration in the Information pane.

tab.

You see a list of interfaces and associated IP-ACLs.

.

Step 4 (Optional) Remove the switches you do not want to include in the IP-ACL by unchecking the check boxes next to the switch addresses.

you want associated with an IPv4-ACL or IPv6-ACL in the Interface field.

).

Step 6 Enter the IP-ACL name in the Profile Name field.

Note This IP-ACL name must have already been created using the Create Profiles dialog box. If not, no filters will be enabled until you to go to the Create Profiles dialog box and create the profile.

to associate the IP-ACL.

You see the newly associated access list in the list of IP-ACLs.

Verifying the IPv4 or IPv6 Configuration

To display the IPv4 or IPv6 configuration information, perform one of the following tasks:

Command

Purpose

Displays Filters Configured for an IPv4-ACL.

Displays Configured IPv6-ACLs.

show ipv6 access-list abc

Displays a Summary of the Specified IPv6-ACL.

show interface mgmt 0

Displays the IPv4-ACL configuration on an interface.

show interface gigabitethernet 2/1

Displays the IPv6-ACL configuration on an interface.

show ip access-list abc

Clears the counters for a specified IPv4-ACL filter entry.

clear ipv6 access-list

Clears the counters for all IPv6-ACLs.

clear ipv6 access-list List1

Clears the counters for a specified IPv6-ACL.

.

- “Displaying the IPv4-ACL or IPv6-ACL Configuration” section

- “Displaying Interface IP-ACL Configuration” section

- “IP-ACL Counter Cleanup” section

Displaying the IPv4-ACL or IPv6-ACL Configuration

command to view the contents of configured IPv4-ACLs. An IPv4-ACL can have one or more filters. (See Example 5-1).

Example 5-1 Displays Filters Configured for an IPv4-ACL

switch# show ip access-list abc

ip access-list abc permit tcp any any (0 matches)

ip access-list abc permit udp any any (0 matches)

ip access-list abc permit icmp any any (0 matches)

ip access-list abc permit ip 10.1.1.0 0.0.0.255 (2 matches)

ip access-list abc permit ip 10.3.70.0 0.0.0.255 (7 matches)

command to view the contents of configured access filters. Each access filter can have several conditions. (See Example 5-2 and Example 5-3).

Example 5-2 Displays Configured IPv6-ACLs

switch# show ipv6 access-list

switch# show ipv6 access-list

IPv6 access list copp-system-acl-bgp6

10 permit tcp any gt 1024 any eq bgp

20 permit tcp any eq bgp any gt 1024

IPv6 access list copp-system-acl-icmp6

10 permit icmp any any echo-request

20 permit icmp any any echo-reply

IPv6 access list copp-system-acl-icmp6-msgs

10 permit icmp any any router-advertisement

20 permit icmp any any router-solicitation

30 permit icmp any any nd-na

40 permit icmp any any nd-ns

50 permit icmp any any mld-query

60 permit icmp any any mld-report

70 permit icmp any any mld-reduction

IPv6 access list copp-system-acl-ntp6

10 permit udp any any eq ntp

20 permit udp any eq ntp any

IPv6 access list copp-system-acl-ospf6

10 permit 89 any any

IPv6 access list copp-system-acl-pim6

10 permit 103 any ff02::d/128

20 permit udp any any eq pim-auto-rp

IPv6 access list copp-system-acl-radius6

Example 5-3 Displays a Summary of the Specified IPv6-ACL

switch# show ipv6 access-list abc

Displaying Interface IP-ACL Configuration

command to display the IPv4-ACL configuration on an interface.

switch# show interface mgmt 0

mgmt0 is up

Hardware is FastEthernet

Address is 000c.30d9.fdbc

Internet address is 172.22.31.113/24

MTU 1500 bytes, BW 100 Mbps full Duplex

ip access-group restrict_mgmt in

35988 packets input, 3105539 bytes

0 multicast frames, 0 compressed

0 input errors, 0 frame, 0 overrun 0 fifo

2495 packets output, 430547 bytes, 0 underruns

0 output errors, 0 collisions, 0 fifo

0 carrier errors

command to display the IPv6-ACL configuration on an interface.

switch# show interface gigabitethernet 2/1

GigabitEthernet2/1 is up

Hardware is GigabitEthernet, address is 000e.38c6.28b0

Internet address is 10.1.1.10/24

MTU 1500 bytes

Port mode is IPS

Speed is 1 Gbps

Beacon is turned off

Auto-Negotiation is turned on

ip access-group RestrictMgmt

5 minutes input rate 1208 bits/sec, 151 bytes/sec, 2 frames/sec

5 minutes output rate 80 bits/sec, 10 bytes/sec, 0 frames/sec

6232 packets input, 400990 bytes

0 multicast frames, 0 compressed

0 input errors, 0 frame, 0 overrun 0 fifo

503 packets output, 27054 bytes, 0 underruns

0 output errors, 0 collisions, 0 fifo

0 carrier errors

IP-ACL Counter Cleanup

command to clear the counters for a specified IPv4-ACL filter entry.

Note You cannot use this command to clear the counters for individual filters.

switch# show ip access-list abc

ip access-list abc permit tcp any any (0 matches)

ip access-list abc permit udp any any (0 matches)

ip access-list abc permit icmp any any (0 matches)

ip access-list abc permit ip 10.1.1.0 0.0.0.255 (2 matches)

ip access-list abc permit ip 10.3.70.0 0.0.0.255 (7 matches)

switch# clear ip access-list counters abc

switch# show ip access-list abc

ip access-list abc permit tcp any any (0 matches)

ip access-list abc permit udp any any (0 matches)

ip access-list abc permit icmp any any (0 matches)

ip access-list abc permit ip 10.1.1.0 0.0.0.255 (0 matches)

ip access-list abc permit ip 10.3.70.0 0.0.0.255 (0 matches)

command to clear the counters for all IPv6-ACLs.

switch# clear ipv6 access-list

command to clear the counters for a specified IPv6-ACL.

switch# clear ipv6 access-list List1

Note You cannot use this command to clear the counters for each individual filter.

Configuration Examples for IP-ACL

To define an IP-ACL that restricts management access using Device Manager, follow these steps:

.

You see the IP-ACL dialog box.

to create an IP-ACL.

You see the Create IP ACL Profiles dialog box.

.

This creates an empty IP-ACL named RestrictMgmt (see Figure 5-3).

Figure 5-3 RestrictMgmt Profile Added to the List

.

You see an empty list of IP filters associated with this IP-ACL.

to create the first IP filter.

You see the Create IP Filter dialog box.

Step 6 Create an IP filter to allow management communications from a trusted subnet:

from the Protocol drop-down menu.

b. Set the source IP address to 10.67.16.0 and the wildcard mask to 0.0.0.255.

Note The wildcard mask denotes a subset of the IP address you want to match against. This allows a range of addresses to match against this filter.

check box for the destination address.

to create this IP filter and add it to the RestrictMgmt IP-ACL.

to create an IP filter that allows communications for all addresses in the 10.67.16.0/24 subnet.

Step 7 Create an IP filter to allow ICMP ping commands:

from the Protocol drop-down menu.

check box for the source address.

check box for the destination address.

from the ICMPType drop-down menu.

to create this IP filter and add it to the RestrictMgmt IP-ACL.

to create an IP filter that allows ICMP ping.

Step 8 Create a final IP Filter to block all other traffic:

from the Protocol drop-down menu.

check box for the source address.

check box for the destination address.

to create this IP filter and add it to the RestrictMgmt IP-ACL.

to close the Create IP Filter dialog box.

to create an IP filter that blocks all other traffic.

Step 9 Apply the RestrictMgmt IP ACL to the mgmt0 interface:

tab in the IP ACL dialog box.

.

You see the Create IP-ACL Interfaces dialog box.

from the Interfaces drop-down menu.

Profile Director.

from the ProfileName drop-down menu.

to apply the RestrictMgmt IP-ACL to the mgmt0 interface.

to apply the new IP-ACL to the mgmt0 interface.

Field Descriptions for IPv4 and IPv6 Access Control Lists

The following are the field descriptions for IPv4 and IPv6 access control lists:

IP ACL Profiles

Field

Description

Name

This is the unique IP protocol filter profile identifier.

Type

This object determines the usage type for this filter profile. This usage type cannot be changed after the profile has been created.

IP ACL Interfaces

Field

Description

ProfileName

This is the unique IP protocol filter profile identifier.

IP Filter Profiles

Field

Description

Action

If it is set to deny, all frames matching this filter will be discarded and scanning of the remainder of the filter list will be aborted. If it is set to permit, all frames matching this filter will be allowed for further bridging or routing processing.

Protocol

This filter protocol value matches the Internet Protocol Number in the frames. These IP numbers are defined in the Network Working Group Request for Comments (RFC) documents. Setting this to '-1' will make the filtering match any IP number.

Address

The source IP address to be matched for this filter. A value of 0 causes all source address to match.

Mask

This is the wildcard mask for the SrcAddress bits that must match. 0 bits in the mask indicate the corresponding bits in the SrcAddress must match in order for the matching to be successful, and 1 bits are don't care bits in the matching. A value of 0 causes only IP frames of source address the same as SrcAddress to match.

PortLow

If Protocol is UDP or TCP, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or less than the value specified for this entry in SrcPortHigh.

PortHigh

If Protocol is UDP or TCP, this is the inclusive upper bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or greater than the value specified for this entry in SrcPortLow. If this value is '0', the UDP or TCP port number is ignored during matching.

Address

The destination IP address to be matched for this filter. A value of 0 causes all source address to match.

Mask

This is the wildcard mask for the DestAddress bits that must match. 0 bits in the mask indicate the corresponding bits in the DestAddress must match in order for the matching to be successful, and 1 bits are don't care bits in the matching. A value of 0 causes only IP frames of source address the same as SrcAddress to match.

PortLow

If Protocol is UDP or TCP, this is the inclusive lower bound of the transport-layer destination port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or less than the value specified for this entry in PortHigh.

PortHigh

If Protocol is UDP or TCP, this is the inclusive upper bound of the transport-layer destination port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or greater than the value specified for this entry in DestPortLow. If this value is '0', the UDP or TCP port number is ignored during matching.

Precedence

The IP traffic precedence parameters in each frame are used to guide the selection of the actual service parameters when transmitting a datagram through a particular network. Most network treats high precedence traffic as more important than other traffic. The IP Precedence value ranges from '0' to '7', with '7' the highest precedence and '0' the lowest precedence. The value '-1' means to match frames of any IP precedence. In other words, the IP precedence parameter will not to checked if this value is '-1'. The precedence level are:

- routine(0) - Routine traffic precedence

- priority(1) - Priority traffic precedence

- immediate(2) - Immediate traffic precedence

- flash(3) - Flash traffic precedence

- flashOverride(4) - Flash-override traffic precedence

- critical(5) - Critical precedence

- internet(6) - Internetwork control traffic precedence

- network(7) - Network control traffic precedence.

TOS

The Type of Service (TOS) of the frame. The TOS values ranges from '0' to '15'. The value '-1' matches any TOS value.

ICMPType

This filter specifies the ICMP message type to be matched. Setting this value to '-1' will make the filtering match any ICMP message type.

ICMPCode

This filter specifies the ICMP message code to be matched. Setting this value to '-1' will make the filtering match any ICMP code.

TCPEstablished

This filter if true specifies that for TCP protocol, in an established connection, a match occurs if the TCP datagram has the ACK,FIN,PSH,RST,SYN or URG control bits set. If false, a match will occur for any TCP datagram.

LogEnabled

Specifies whether filtered frames will be logged by the filtering subsystem or not. If true, then all frames will be logged. If false, then no frame will be logged.

Configuring Certificate Authorities and Digital Certificates

This chapter includes the following topics:

- Information About Certificate Authorities and Digital Certificates

- Default Settings

- Configuring CAs and Digital Certificates

- Verifying Certificate Authorities and Digital Certificates Configuration

- Configuration Examples

Information About Certificate Authorities and Digital Certificates

Public Key Infrastructure (PKI) support provides the means for the Cisco MDS 9000 Family switches to obtain and use digital certificates for secure communication in the network. PKI support provides manageability and scalability for IPsec/IKE and SSH.

Certificate Authorities (CAs) manage certificate requests and issue certificates to participating entities such as hosts, network devices, or users. The CAs provide centralized key management for the participating entities.

Digital signatures, based on public key cryptography, digitally authenticate devices and individual users. In public key cryptography, such as the RSA encryption system, each device or user has a key-pair containing both a private key and a public key. The private key is kept secret and is known only to the owning device or user only. However, the public key is known to everybody. The keys act as complements. Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a sender’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. This process relies on the receiver having a copy of the sender’s public key and knowing with a high degree of certainty that it really does belong to the sender and not to someone pretending to be the sender.

This section includes the following topics:

- Purpose of CAs and Digital Certificates

- Trust Model, Trust Points, and Identity CAs

- RSA Key-Pairs and Identity Certificates

- Multiple Trusted CA Support

- PKI Enrollment Support

- Manual Enrollment Using Cut-and-Paste Method

- Multiple RSA Key-Pair and Identity CA Support

- Peer Certificate Verification

- CRL Downloading, Caching, and Checking Support

- OCSP Support

- Import and Export Support for Certificates and Associated Key-Pairs

Purpose of CAs and Digital Certificates

CAs manage certificate requests and issue certificates to participating entities such as hosts, network devices, or users. The CAs provide centralized key management for the participating entities.

Digital signatures, based on public key cryptography, digitally authenticate devices and individual users. In public key cryptography, such as the RSA encryption system, each device or user has a key-pair containing both a private key and a public key. The private key is kept secret and is known only to the owning device or user only. However, the public key is known to everybody. The keys act as complements. Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a sender’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. This process relies on the receiver having a copy of the sender’s public key and knowing with a high degree of certainty that it really does belong to the sender and not to someone pretending to be the sender.

Digital certificates link the digital signature to the sender. A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity’s public key. The certificate is itself signed by a CA, a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.

To validate the signature of the CA, the receiver must first know the CA’s public key. Normally this process is handled out-of-band or through an operation done at installation. For instance, most web browsers are configured with the public keys of several CAs by default. The Internet Key Exchange (IKE), an essential component of IPsec, can use digital signatures to scalably authenticate peer devices before setting up security associations.

Trust Model, Trust Points, and Identity CAs

and is a mandatory step in trusting a CA.

. This information consists of CA certificate (or certificate chain in case of a subordinate CA) and the certificate revocation checking information.

.

RSA Key-Pairs and Identity Certificates

You can generate one or more RSA key-pairs and associate each RSA key-pair with a trust point CA where the MDS switch intends to enroll to obtain an identity certificate. The MDS switch needs only one identity per CA, which consists of one key-pair and one identity certificate per CA.

Cisco MDS NX-OS allows you to generate RSA key-pairs with a configurable key size (or modulus). The default key size is 512. You can also configure an RSA key-pair label. The default key label is the switch fully qualified domain name (FQDN).

The following list summarizes the relationship between trust points, RSA key-pairs, and identity certificates:

- A trust point corresponds to a specific CA that the MDS switch trusts for peer certificate verification for any application (such as IKE or SSH).

- An MDS switch can have many trust points and all applications on the switch can trust a peer certificate issued by any of the trust point CAs.

- A trust point is not restricted to a specific application.

- An MDS switch enrolls with the CA corresponding to the trust point to obtain an identity certificate. You can enroll your switch with multiple trust points thereby obtaining a separate identity certificate from each trust point. The identity certificates are used by applications depending upon the purposes specified in the certificate by the issuing CA. The purpose of a certificate is stored in the certificate as certificate extensions.

- When enrolling with a trust point, you must specify an RSA key-pair to be certified. This key-pair must be generated and associated to the trust point before generating the enrollment request. The association between the trust point, key-pair, and identity certificate is valid until it is explicitly removed by deleting the certificate, key-pair, or trust point.

- The subject name in the identity certificate is the fully qualified domain name for the MDS switch.

- You can generate one or more RSA key-pairs on a switch and each can be associated to one or more trust points. But no more than one key-pair can be associated to a trust point, which means only one identity certificate is allowed from a CA.

- If multiple identity certificates (each from a distinct CA) have been obtained, the certificate that an application selects to use in a security protocol exchange with a peer is application specific.

- You do not need to designate one or more trust points for an application. Any application can use any certificate issued by any trust point as long as the certificate purpose satisfies the application requirements.

- You do not need more than one identity certificate from a trust point or more than one key-pair to be associated to a trust point. A CA certifies a given identity (name) only once and does not issue multiple certificates with the same subject name. If you need more than one identity certificate for a CA, then define another trust point for the same CA, associate another key-pair to it, and have it certified, provided CA allows multiple certificates with the same subject name.

Multiple Trusted CA Support

An MDS switch can be configured to trust multiple CAs by configuring multiple trust points and associating each with a distinct CA. With multiple trusted CAs, you do not have to enroll a switch with the specific CA that issued a certificate to a peer. Instead, you configure the switch with multiple trusted CAs that the peer trusts. A switch can then use a configured trusted CA to verify certificates offered by a peer that were not issued by the same CA defined in the identity of the switch.

Configuring multiple trusted CAs allows two or more switches enrolled under different domains (different CAs) to verify the identity of each other when using IKE to set up IPsec tunnels.

PKI Enrollment Support

Enrollment is the process of obtaining an identity certificate for the switch that is used for applications such as IPsec/IKE or SSH. It occurs between the switch requesting the certificate and the certificate authority.

The PKI enrollment process for a switch involves the following steps:

1. Generate an RSA private and public key-pair on the switch.

2. Generate a certificate request in standard format and forward it to the CA.

3. Manual intervention at the CA server by the CA administrator may be required to approve the enrollment request, when it is received by the CA.

4. Receive the issued certificate back from the CA, signed with the CA’s private key.

5. Write the certificate into a nonvolatile storage area on the switch (bootflash).

Manual Enrollment Using Cut-and-Paste Method

Cisco MDS NX-OS supports certificate retrieval and enrollment using a manual cut-and-paste method. Cut-and-paste enrollment literally means you must cut and paste the certificate requests and resulting certificates between the switch and the CA, as follows:

1. Create an enrollment certificate request, which is displayed in base64-encoded text form.

2. Cut and paste the encoded certificate request text in an e-mail message or in a web form and send it to the CA.

3. Receive the issued certificate (in base64-encoded text form) from the CA in an e-mail message or in a web browser download.

4. Cut and paste the issued certificate to the switch using the certificate import facility.

Note DCNM-SAN does not support cut and paste. Instead, it allows the enrollment request (certificate signing request) to be saved in a file to be sent manually to the CA.

Multiple RSA Key-Pair and Identity CA Support

Multiple identity CA support enables the switch to enroll with more than one trust point. This results in multiple identity certificates; each from a distinct CA. This allows the switch to participate in IPsec and other applications with many peers using certificates issued by appropriate CAs that are acceptable to those peers.

The multiple RSA key-pair support feature allows the switch to maintain a distinct key pair for each CA with which it is enrolled. Thus, it can match policy requirements for each CA without conflicting with the requirements specified by the other CAs, such as key length. The switch can generate multiple RSA key-pairs and associate each key-pair with a distinct trust point. Thereafter, when enrolling with a trust point, the associated key-pair is used to construct the certificate request.

Peer Certificate Verification

The PKI support on an MDS switch provides the means to verify peer certificates. The switch verifies certificates presented by peers during security exchanges pertaining to applications, such as IPsec/IKE and SSH. The applications verify the validity of the peer certificates presented to them. The peer certificate verification process involves the following steps:

- Verifies that the peer certificate is issued by one of the locally trusted CAs.

- Verifies that the peer certificate is valid (not expired) with respect to current time.

- Verifies that the peer certificate is not yet revoked by the issuing CA.

For revocation checking, two methods are supported: certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP). A trust point uses one or both of these methods to verify that the peer certificate has not been revoked.

CRL Downloading, Caching, and Checking Support

Certificate revocation lists (CRLs) are maintained by CAs to give information of prematurely revoked certificates, and the CRLs are published in a repository. The download URL is made public and also specified in all issued certificates. A client verifying a peer’s certificate should obtain the latest CRL from the issuing CA and use it to determine if the certificate has been revoked. A client can cache the CRLs of some or all of its trusted CAs locally and use them later if necessary until the CRLs expire.

Cisco MDS NX-OS allows the manual configuration of pre-downloaded of CRLs for the trust points, and then caches them in the switch bootflash (cert-store). During the verification of a peer certificate by IPsec or SSH, the issuing CA’s CRL is consulted only if the CRL has already been cached locally and the revocation checking is configured to use CRL. Otherwise, CRL checking is not performed and the certificate is considered to be not revoked if no other revocation checking methods are configured. This mode of CRL checking is called CRL optional.

OCSP Support

Online Certificate Status Protocol (OCSP) facilitates online certificate revocation checking. You can specify an OCSP URL for each trust point. Applications choose the revocation checking mechanisms in a specified order. The choices are CRL, OCSP, none, or a combination of these methods.

Import and Export Support for Certificates and Associated Key-Pairs

As part of the CA authentication and enrollment process, the subordinate CA certificate (or certificate chain) and identity certificates can be imported in standard PEM (base64) format.

The complete identity information in a trust point can be exported to a file in the password-protected PKCS#12 standard format. It can be later imported to the same switch (for example, after a system crash) or to a replacement switch. The information in a PKCS#12 file consists of the RSA key-pair, the identity certificate, and the CA certificate (or chain).

Maximum Limits

lists the maximum limits for CAs and digital certificate parameters.

Table 6-1 Maximum Limits for CA and Digital Certificate

Feature

Maximum Limit

Trust points declared on a switch

16

RSA key-pairs generated on a switch

16

Identity certificates configured on a switch

16

Certificates in a CA certificate chain

10

Trust points authenticated to a specific CA

10

Default Settings

lists the default settings for CAs and digital certificate parameters.

Table 6-2 Default CA and Digital Certificate Parameters

Parameters

Default

Trust point

None

RSA key-pair

None

RSA key-pair label

Switch FQDN

RSA key-pair modulus

512

RSA key-pair exportable

Yes

Revocation check method of trust point

CRL

Configuring CAs and Digital Certificates

This section describes the tasks you must perform to allow CAs and digital certificates your Cisco MDS switch device to interoperate. This section includes the following sections:

- Configuring the Host Name and IP Domain Name

- Generating an RSA Key Pair

- Creating a Trust Point CA Association

- Copying Files to Bootflash

- Authenticating the CA

- Confirming CA Authentication

- Configuring Certificate Revocation Checking Methods

- Generating Certificate Requests

- Installing Identity Certificates

- Saving Your Configuration

- Ensuring Trust Point Configurations Persist Across Reboots

- Monitoring and Maintaining CA and Certificates Configuration

Configuring the Host Name and IP Domain Name

You must configure the host name and IP domain name of the switch if they are not already configured. This is required because switch FQDN is used as the subject in the identity certificate. Also, the switch FQDN is used as a default key label when none is specified during key-pair generation. For example, a certificate named SwitchA.example.com is based on a switch host name of SwitchA and a switch IP domain name of example.com.

Caution Changing the host name or IP domain name after generating the certificate can invalidate the certificate.

Detailed Steps

To configure the host name and IP domain name of the switch, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Configures the host name (SwitchA) of the switch.

Step 3

Configures the IP domain name (example.com) of the switch.

.

Generating an RSA Key Pair

RSA key-pairs are used to sign and/or encrypt and decrypt the security payload during security protocol exchanges for applications such as IKE/IPsec and SSH, and they are required before you can obtain a certificate for your switch.

Detailed Steps

To generate an RSA key-pair, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Generates an RSA key-pair with the switch FQDN as the default label and 512 as the default modulus. By default, the key is not exportable.

Note The security policy (or requirement) at the local site (MDS switch) and at the CA (where enrollment is planned) are considered in deciding the appropriate key modulus.

Note The maximum number of key-pairs you can configure on a switch is 16.

Generates an RSA key-pair with the label SwitchA and modulus 768. Valid modulus values are 512, 768, 1024, 1536, and 2048. By default, the key is not exportable.

Generates an RSA key-pair with the switch FQDN as the default label and 512 as the default modulus. The key is exportable.

Caution The exportability of a key-pair cannot be changed after key-pair generation.

Note Only exportable key-pairs can be exported in PKCS#12 format.

To generate an RSA key-pair, follow these steps:

in the Information pane.

tab.

.

Step 4 Select the switches for which you want to create the RSA key-pair.

Step 5 Assign a name to the RSA key-pair.

Step 6 Select the Size or modulus values. Valid modulus values are 512, 768, 1024, 1536, and 2048.

Note The security policy (or requirement) at the local site (MDS switch) and at the CA (where enrollment is planned) are considered in deciding the appropriate key modulus.

Note The maximum number of key-pairs you can configure on a switch is 16.

check box if you want the key to be exportable.

Caution The exportability of a key-pair cannot be changed after key-pair generation.

Note Only exportable key-pairs can be exported in PKCS#12 format.

to create the RSA key pair.

Creating a Trust Point CA Association

Detailed Steps

To create a trust point CA association, follow these steps:

Command

Purpose

Step 1

switch(config-trustpoint)#

Declares a trust point CA that the switch should trust and enters trust point configuration submode.

Note The maximum number of trust points you can declare on a switch is 16.

Removes the trust point CA.

Step 2

Specifies manual cut-and-paste certificate enrollment (default).

Note Manual cut-and-paste certificate enrollment is the only method supported for enrollment.

Step 3

Specifies the label of the RSA key-pair to be associated to this trust point for the purpose of enrollment. It was generated earlier in the “Generating an RSA Key Pair” section. Only one RSA key-pair can be specified per CA.

Disassociates the RSA key-pair from the trust point (default).

Step 4

switch#

Exits trust point configuration submode.

Step 5

Copies the running configuration to the startup configuration to ensure the configuration is persistent across reboots.

To create a trust point CA association, follow these steps:

in the Physical Attributes pane.

tab in the Information Pane.

.

drop-down menu.

Step 5 Assign a name to the trust point CA.

Step 6 Select a key-pair name to be associated with this trust point for enrollment. It was generated earlier in the “Generating an RSA Key Pair” section. Only one RSA key-pair can be specified per CA.

Step 7 From the RevokeCheckMethod drop-down menu, select the certificate revocation method that you would like to use. You can use CRL, OCSP, CRL OCSP, or OCSP CRL to check for certificate revocation.

The CRL OCSP option checks for revoked certificates first in the locally stored CRL. If not found, the switch uses OCSP to check the revoked certificates on the URL specified in Step 7.

Step 8 Enter the OCSP URL if you selected an OCSP certificate revocation method.

Note The OSCP URL must be configured before configuring the revocation checking method.

to successfully create the trust point CA.

Copying Files to Bootflash

Detailed Steps

To copy files to bootflash using Device Manager, follow these steps:

.

Step 2 Select bootflash in the Device field.

.

as the Protocol field.

Step 5 Click the Browse button to locate the appropriate file to copy to bootflash.

to apply these changes.

Authenticating the CA

The configuration process of trusting a CA is complete only when the CA is authenticated to the MDS switch. The switch must authenticate the CA. It does this by obtaining the self-signed certificate of the CA in PEM format, which contains the public key of the CA. Because the certificate of the CA is self-signed (the CA signs its own certificate) the public key of the CA should be manually authenticated by contacting the CA administrator to compare the fingerprint of the CA certificate.

Note If the CA being authenticated is not a self-signed CA (that is, it is a subordinate CA to another CA, which itself may be a subordinate to yet another CA, and so on, finally ending in a self-signed CA), then the full list of the CA certificates of all the CAs in the certification chain needs to be input during the CA authentication step. This is called the CA certificate chain of the CA being authenticated. The maximum number of certificates in a CA certificate chain is 10.

Detailed Steps

To authenticate a CA, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

Step 3 From the Command field drop-down menu, select the appropriate option.

option is provided to authenticate a CA and install its CA certificate or certificate chain in a trust point.

dialog box. It is the file name containing the CA certificate or chain in the bootflash:filename format.

Note You can authenticate a maximum of 10 trust points to a specific CA.

Note If you do not see the required file in the Import Certificate dialog box, make sure that you copy the file to bootflash. See “$paratext>” section.

.

Authentication is then confirmed or not confirmed depending on whether or not the certificate can be accepted after manual verification of its fingerprint.

To authenticate the certificate of the CA by cutting and pasting the certificate from an e-mail message or a website, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

input (cut & paste) CA certificate (chain) in PEM format;

end the input with a line containing only END OF INPUT :

Fingerprint(s): MD5 Fingerprint=65:84:9A:27:D5:71:03:33:9C:12:23:92:38:6F:78:12

Prompts you to cut and paste the certificate of the CA. Use the same name that you used when declaring the CA.

Note The maximum number of trust points you can authenticate to a specific CA is 10.

Note For subordinate CA authentication, the full chain of CA certificates ending in a self-signed CA is required because the CA chain is needed for certificate verification as well as for PKCS#12 format export.

Confirming CA Authentication

As mentioned in step 5 of “Authenticating the CA” section, CA authentication is required to be followed by CA confirmation in order to accept the CA certificate based on its fingerprint verification.

Detailed Steps

To confirm CA authentication, follow these steps:

in the Physical Attributes pane.

tab in the Information Pane.

Step 3 Make a note of the CA certificate fingerprint displayed in the IssuerCert FingerPrint column for the trust point row in question. Compare the CA certificate fingerprint with the fingerprint already communicated by the CA (obtained from the CA web site).

command.

.

Configuring Certificate Revocation Checking Methods

During security exchanges with a client (for example, an IKE peer or SSH user), the MDS switch performs the certificate verification of the peer certificate sent by the client and the verification process may involve certificate revocation status checking.

You can use different methods for checking for revoked sender certificates. You can configure the switch to check the CRL downloaded from the CA (see the “Configuring a CRL” section), you can use OSCP if it is supported in your network, or both. Downloading the CRL and checking locally does not generate traffic in your network. However, certificates can be revoked between downloads and your switch would not be aware of the revocation. OCSP provides the means to check the current CRL on the CA. However, OCSP can generate network traffic that can impact network efficiency. Using both local CRL checking and OCSP provides the most secure method for checking for revoked certificates.

Note You must authenticate the CA before configuring certificate revocation checking.

DCNM-SAN allows you to configure certificate revocation checking methods when you are creating a trust point CA. See “Creating a Trust Point CA Association” section.

Detailed Steps

To configure certificate revocation checking methods, follow these steps:

Command

Purpose

Step 1

switch(config-trustpoint)#

Declares a trust point CA that the switch should trust and enters trust point configuration submode.

Step 2

Specifies the for OCSP to use to check for revoked certificates.

Removes the URL for OCSP.

Step 3

Specifies OCSP as the revocation checking method to be employed during verification of peer certificates issued by the same CA as that of this trust point.

Note The OSCP URL must be configured before specifying OSCP as a revocation checking method.

Specifies CRL (default) as the revocation checking method to be employed during verification of peer certificates issued by the same CA as that of this trust point.

Specifies CRL as the first revocation checking method and OCSP as the next method. If the CRL method fails (for example, due to the CRL is not found or has expired) to be used during verification of peer certificates issued by the same CA as that of this trust point, then OSCP is used.

Note The OSCP URL must be configured before specifying OSCP as a revocation checking method.

Does not check for revoked certificates.

Reverts to default method.

Generating Certificate Requests

You must generate a request to obtain identity certificates from the associated trust point CA for each of your switch’s RSA key pairs. You must then cut and paste the displayed request into an e-mail message or in a website form for the CA.

Detailed Steps

To generate a request for signed certificates from the CA, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Create the certificate request ..

Create a challenge password. You will need to verbally provide this

password to the CA Administrator in order to revoke your certificate.

For security reasons your password will not be saved in the configuration.

Please make a note of it.

The certificate request will be displayed...

-----BEGIN CERTIFICATE REQUEST-----

MIIBqzCCARQCAQAwHDEaMBgGA1UEAxMRVmVnYXMtMS5jaXNjby5jb20wgZ8wDQYJ

KoZIhvcNAQEBBQADgY0AMIGJAoGBAL8Y1UAJ2NC7jUJ1DVaSMqNIgJ2kt8rl4lKY

0JC6ManNy4qxk8VeMXZSiLJ4JgTzKWdxbLDkTTysnjuCXGvjb+wj0hEhv/y51T9y

P2NJJ8ornqShrvFZgC7ysN/PyMwKcgzhbVpj+rargZvHtGJ91XTq4WoVkSCzXv8S

VqyH0vEvAgMBAAGgTzAVBgkqhkiG9w0BCQcxCBMGbmJ2MTIzMDYGCSqGSIb3DQEJ

DjEpMCcwJQYDVR0RAQH/BBswGYIRVmVnYXMtMS5jaXNjby5jb22HBKwWH6IwDQYJ

KoZIhvcNAQEEBQADgYEAkT60KER6Qo8nj0sDXZVHSfJZh6K6JtDz3Gkd99GlFWgt

PftrNcWUE/pw6HayfQl2T3ecgNwel2d15133YBF2bktExiI6Ul88nTOjglXMjja8

8a23bNDpNsM8rklwA6hWkrVL8NUZEFJxqbjfngPNTZacJCUS6ZqKCMetbKytUx0=

-----END CERTIFICATE REQUEST-----

Generates a certificate request for an authenticated CA.

Note The challenge password is not saved with the configuration. This password is required in the event that your certificate needs to be revoked, so you must remember this password.

To generate a request for signed certificates from the CA, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

option from the Command drop-down menu.

action. See “Authenticating the CA” section.

Step 4 Enter the output file name for storing the generated certificate request.

It will be used to store the CSR generated in PEM format. Use the format bootflash:filename. This CSR should be submitted to the CA to get the identity certificate. Once the identity certificate is obtained, it should be installed in this trust point. See “Installing Identity Certificates” section.

password to be included in the CSR.

Note The challenge password is not saved with the configuration. This password is required in the event that your certificate needs to be revoked, so you must remember this password.

to save the changes.

Installing Identity Certificates

You receive the identity certificate from the CA by e-mail or through a web browser in base64 encoded text form. You must install the identity certificate from the CA by cutting and pasting the encoded text using the CLI import facility.

Detailed Steps

To install an identity certificate received from the CA by e-mail or through a web browser, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

input (cut & paste) certificate in PEM format:

Prompts you to cut and paste the identity certificate for the CA named admin-ca.

Note The maximum number of identify certificates you can configure on a switch is 16.

To install an identity certificate received from the CA, follow these steps:

in the Physical Attributes pane.

tab, in the Information pane.

option from the Command drop-down menu to import an identity certificate in this trust point. The identity certificate is obtained from the corresponding CA for a CSR that was generated previously (see “Generating Certificate Requests” section).

Note The identity certificate should be available in PEM format in a file in bootflash.

Step 4 Enter the name of the certificate file that should have been copied to bootflash in the URL field in the bootflash:filename format.

If successful, the values of the identity certificate and its related objects, like the certificate file name, are automatically updated with the appropriate values as per the corresponding attributes in the identity certificate.

Saving Your Configuration

Save your work when you make configuration changes or the information is lost when you exit.

Detailed Steps

To save your configuration, follow these steps:

in the Physical Attributes pane.

Step 2 Select the switch configuration including the RSA key pairs and certificates.

to save the changes.

Ensuring Trust Point Configurations Persist Across Reboots

The trust point configuration is a normal Cisco NX-OS configuration that persists across system reboots only if you copy it explicitly to the startup configuration. The certificates, key pairs, and CRL associated with a trust point are automatically persistent if you have already copied the trust point configuration in the startup configuration. Conversely, if the trust point configuration is not copied to the startup configuration, the certificates, key pairs, and CRL associated with it are not persistent since they require the corresponding trust point configuration after a reboot. Always copy the running configuration to the startup configuration to ensure that the configured certificates, key pairs, and CRLs are persistent. Also, save the running configuration after deleting a certificate or key pair to ensure that the deletions are permanent.

The certificates and CRL associated with a trust point automatically become persistent when imported (that is, without an explicitly copying to the startup configuration) if the specific trust point is already saved in startup configuration.

We also recommend that you create a password-protected backup of the identity certificates and save it to an external server (see the “Exporting and Importing Identity Information in PKCS#12 Format” section).

Note Copying the configuration to an external server does include the certificates and key pairs.

Monitoring and Maintaining CA and Certificates Configuration

The tasks in the section are optional. This section includes the following topics:

- Exporting and Importing Identity Information in PKCS#12 Format

- Configuring a CRL

- Deleting Certificates from the CA Configuration

- Deleting RSA Key Pairs from Your Switch

- Configuration Examples

Exporting and Importing Identity Information in PKCS#12 Format

You can export the identity certificate along with the RSA key pair and CA certificate (or the entire chain in the case of a subordinate CA) of a trust point to a PKCS#12 file for backup purposes. You can later import the certificate and RSA key pair to recover from a system crash on your switch or when you replace the supervisor modules.

Note Only the bootflash:filename format local syntax is supported when specifying the export and import URL.

Detailed Steps

To export a certificate and key-pair to a PKCS#12-formatted file, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Exports the identity certificate and associated key-pair and CA certificates for trust point admin-ca to the file bootflash:adminid.p12 in PKCS#12 format, protected using password nbv123.

Step 3

switch#

Returns to EXEC mode.

Step 4

Copies the PKCS#12 format file to a TFTP server.

To export a certificate and key pair to a PKCS#12-formatted file, follow these steps:

in the Physical Attributes pane.

tab in the Information Pane (see Figure 6-1).

option in the Command drop-down menu to export the key pair, identity certificate, and the CA certificate or certificate chain in PKCS#12 format from the selected trust point.

Figure 6-1 Pkcs12export Option Exports a Key Pair

Step 4 Enter the output file name as bootflash:filename to store the exported PKCS#12 identity.

Step 5 Enter the required password. The password is set for encoding the PKCS#12 data. On successful completion, the exported data is available in bootflash in the specified file.

to save the changes.

To import a certificate and key-pair from a PKCS#12-formatted file, follow these steps:

Command

Purpose

Step 1

Copies the PKCS#12 format file from a TFTP server.

Step 2

switch(config)#

Enters configuration mode.

Step 3

Imports the identity certificate and associated key-pair and CA certificates for trust point admin-ca from the file bootflash:adminid.p12 in PKCS#12 format, protected using password nbv123.

To import a certificate and key pair formatted as a PKCS#12 formatted file, follow these steps:

in the Physical Attributes pane.

tab in the Information pane (see Figure 6-1).

option from the Command drop-down menu to import the key-pair, identity certificate, and the CA certificate or certificate chain in the PKCS#12 format to the selected trust point.

Step 4 Enter the input in the bootflash:filename format containing the PKCS#12 identity.

Step 5 Enter the required password. The password is set for decoding the PKCS#12 data. On completion, the imported data is available in bootflash in the specified file.

to save the changes.

On completion the trust point is created in the RSA key-pair table corresponding to the imported key pair. The certificate information is updated in the trust point.

Note The trust point must be empty (with no RSA key pair associated with it and no CA is associated with it using CA authentication) for the PKCS#12 file import to succeed.

Configuring a CRL

Detailed Steps

To import the CRL from a file to a trust point, follow these steps:

Command

Purpose

Step 1

Downloads the CRL.

Step 2

switch(config)#

Enters configuration mode.

Step 3

Configures or replaces the current CRL with the one specified in the file.

To configure the CRL from a file to a trust point, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

option from the Command drop-down menu to import the CRL to the selected trust point.

Step 4 Enter the input file name with the CRL in the bootflash:filename format, in the URL field.

to save the changes.

Deleting Certificates from the CA Configuration

You can delete the identity certificates and CA certificates that are configured in a trust point. You must first delete the identity certificate, followed by the CA certificates. After deleting the identity certificate, you can disassociate the RSA key-pair from a trust point. The certificate deletion is necessary to remove expired or revoked certificates, certificates whose key-pairs are compromised (or suspected to be compromised) or CAs that are no longer trusted.

Detailed Steps

To delete the CA certificate (or the entire chain in the case of a subordinate CA) from a trust point, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Enters trustpoint configuration submode.

Step 3

Deletes the CA certificate or certificate chain.

Step 4

Deletes the identity certificate.

Forces the deletion of the identity certificate.
option to delete it. This ensures that the administrator does not mistakenly delete the last-most or only identity certificate and leave the applications (such as IKE and SSH) without a certificate to use.

Step 5

switch#

Returns to EXEC mode.

Step 6

Copies the running configuration to the startup configuration to ensure the configuration is persistent across reboots.

To delete the CA certificate (or the entire chain in the case of a subordinate CA) from a trust point using DCNM-SAN, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

option from the Command drop-down menu to delete the identity certificate from a trust point.

Note If the identity certificate being deleted is the last-most or only identity certificate in the device, you must use the forcecertdelete action to delete it. This ensures that the administrator does not mistakenly delete the last-most or only identity certificate and leave the applications (such as IKE and SSH) without a certificate to use.

to save the changes.

in the Command drop-down menu.

Deleting RSA Key Pairs from Your Switch

Under certain circumstances you may want to delete your switch’s RSA key pairs. For example, if you believe the RSA key pairs were compromised in some way and should no longer be used, you should delete the key pairs.

Detailed Steps

To delete RSA key-pairs from your switch, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Deletes the RSA key-pair whose label is MyKey.

Step 3

switch#

Returns to EXEC mode.

Step 4

Copies the running configuration to the startup configuration to ensure the configuration is persistent across reboots.

To delete RSA key pairs from your switch, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

.

in the Confirmation dialog box.

Note After you delete RSA key pairs from a switch, ask the CA administrator to revoke your switch’s certificates at the CA. You must supply the challenge password you created when you originally requested the certificates. See “Generating Certificate Requests” section.

Verifying Certificate Authorities and Digital Certificates Configuration

To display certificate authorities and digital certificates configuration information, perform one of the following tasks:

Command

Purpose

Displays information about the switch’s RSA public keys.

Displays information on CA and identity certificates.

Displays information about CA CRLs.

Displays information about CA trust points.

.

Configuration Examples

This section shows an example of the tasks you can use to configure certificates and CRLs on the Cisco MDS 9000 Family switches using the Microsoft Windows Certificate server.

This section includes the following topics:

- Configuring Certificates on the MDS Switch

- Downloading a CA Certificate

- Requesting an Identity Certificate

- Revoking a Certificate

- Generating and Publishing the CRL

- Downloading the CRL

- Importing the CRL

Configuring Certificates on the MDS Switch

To configure certificates on an MDS switch, follow these steps:

Step 1 Configure the switch FQDN.

switch# config t

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

switch(config)# switchname Vegas-1

Vegas-1(config)#

Step 2 Configure the DNS domain name for the switch.

Vegas-1(config)# ip domain-name cisco.com

Vegas-1(config)#

Step 3 Create a trust point.

Vegas-1(config)# crypto ca trustpoint myCA

Vegas-1(config-trustpoint)# exit

Vegas-1(config)# do show crypto ca trustpoints

trustpoint: myCA; key:

revokation methods: crl

Vegas-1(config)#

Step 4 Create an RSA key-pair for the switch.

Vegas-1(config)# crypto key generate rsa label myKey exportable modulus 1024

Vegas-1(config)# do show crypto key mypubkey rsa

key label: myKey

key size: 1024

exportable: yes

Vegas-1(config)#

Step 5 Associate the RSA key-pair to the trust point.

Vegas-1(config)# crypto ca trustpoint myCA

Vegas-1(config-trustpoint)# rsakeypair myKey

Vegas-1(config-trustpoint)# exit

Vegas-1(config)# do show crypto ca trustpoints

trustpoint: myCA; key: myKey

revokation methods: crl

Vegas-1(config)#

Step 6 Download the CA certificate from the Microsoft Certificate Service web interface (see the “Downloading a CA Certificate” section)

Step 7 Authenticate the CA that you want to enroll to the trust point.

Vegas-1(config)# crypto ca authenticate myCA

input (cut & paste) CA certificate (chain) in PEM format;

end the input with a line containing only END OF INPUT :

-----BEGIN CERTIFICATE-----

MIIC4jCCAoygAwIBAgIQBWDSiay0GZRPSRIljK0ZejANBgkqhkiG9w0BAQUFADCB

kDEgMB4GCSqGSIb3DQEJARYRYW1hbmRrZUBjaXNjby5jb20xCzAJBgNVBAYTAklO

MRIwEAYDVQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdhbG9yZTEOMAwGA1UE

ChMFQ2lzY28xEzARBgNVBAsTCm5ldHN0b3JhZ2UxEjAQBgNVBAMTCUFwYXJuYSBD

QTAeFw0wNTA1MDMyMjQ2MzdaFw0wNzA1MDMyMjU1MTdaMIGQMSAwHgYJKoZIhvcN

AQkBFhFhbWFuZGtlQGNpc2NvLmNvbTELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUth

cm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQ4wDAYDVQQKEwVDaXNjbzETMBEG

A1UECxMKbmV0c3RvcmFnZTESMBAGA1UEAxMJQXBhcm5hIENBMFwwDQYJKoZIhvcN

AQEBBQADSwAwSAJBAMW/7b3+DXJPANBsIHHzluNccNM87ypyzwuoSNZXOMpeRXXI

OzyBAgiXT2ASFuUOwQ1iDM8rO/41jf8RxvYKvysCAwEAAaOBvzCBvDALBgNVHQ8E

BAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUJyjyRoMbrCNMRU2OyRhQ

GgsWbHEwawYDVR0fBGQwYjAuoCygKoYoaHR0cDovL3NzZS0wOC9DZXJ0RW5yb2xs

L0FwYXJuYSUyMENBLmNybDAwoC6gLIYqZmlsZTovL1xcc3NlLTA4XENlcnRFbnJv

bGxcQXBhcm5hJTIwQ0EuY3JsMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB

BQUAA0EAHv6UQ+8nE399Tww+KaGr0g0NIJaqNgLh0AFcT0rEyuyt/WYGPzksF9Ea

NBG7E0oN66zex0EOEfG1Vs6mXp1//w==

-----END CERTIFICATE-----

END OF INPUT

Fingerprint(s): MD5 Fingerprint=65:84:9A:27:D5:71:03:33:9C:12:23:92:38:6F:78:12

Do you accept this certificate? [yes/no]:y

Vegas-1(config)#

Vegas-1(config)# do show crypto ca certificates

Trustpoint: myCA

CA certificate 0:

subject= /emailAddress=admin@yourcompany.com/C=IN/ST=Karnataka/L=Bangalore/O=Yourcompany/O

U=netstorage/CN=Aparna CA

issuer= /emailAddress=admin@yourcompany.com/C=IN/ST=Karnataka/L=Bangalore/O=Yourcompany/OU

=netstorage/CN=Aparna CA

serial=0560D289ACB419944F4912258CAD197A

notBefore=May 3 22:46:37 2005 GMT

notAfter=May 3 22:55:17 2007 GMT

MD5 Fingerprint=65:84:9A:27:D5:71:03:33:9C:12:23:92:38:6F:78:12

purposes: sslserver sslclient ike

Step 8 Generate a request certificate to use to enroll with a trust point.

Vegas-1(config)# crypto ca enroll myCA

Create the certificate request ..

Create a challenge password. You will need to verbally provide this

password to the CA Administrator in order to revoke your certificate.

For security reasons your password will not be saved in the configuration.

Please make a note of it.

Password:nbv123

The subject name in the certificate will be: Vegas-1.cisco.com

Include the switch serial number in the subject name? [yes/no]:no

Include an IP address in the subject name [yes/no]:yes

ip address:10.10.1.1

The certificate request will be displayed...

-----BEGIN CERTIFICATE REQUEST-----

MIIBqzCCARQCAQAwHDEaMBgGA1UEAxMRVmVnYXMtMS5jaXNjby5jb20wgZ8wDQYJ

KoZIhvcNAQEBBQADgY0AMIGJAoGBAL8Y1UAJ2NC7jUJ1DVaSMqNIgJ2kt8rl4lKY

0JC6ManNy4qxk8VeMXZSiLJ4JgTzKWdxbLDkTTysnjuCXGvjb+wj0hEhv/y51T9y

P2NJJ8ornqShrvFZgC7ysN/PyMwKcgzhbVpj+rargZvHtGJ91XTq4WoVkSCzXv8S

VqyH0vEvAgMBAAGgTzAVBgkqhkiG9w0BCQcxCBMGbmJ2MTIzMDYGCSqGSIb3DQEJ

DjEpMCcwJQYDVR0RAQH/BBswGYIRVmVnYXMtMS5jaXNjby5jb22HBKwWH6IwDQYJ

KoZIhvcNAQEEBQADgYEAkT60KER6Qo8nj0sDXZVHSfJZh6K6JtDz3Gkd99GlFWgt

PftrNcWUE/pw6HayfQl2T3ecgNwel2d15133YBF2bktExiI6Ul88nTOjglXMjja8

8a23bNDpNsM8rklwA6hWkrVL8NUZEFJxqbjfngPNTZacJCUS6ZqKCMetbKytUx0=

-----END CERTIFICATE REQUEST-----

Vegas-1(config)#

Step 10 Import the identity certificate.

Vegas-1(config)# crypto ca import myCA certificate

input (cut & paste) certificate in PEM format:

-----BEGIN CERTIFICATE-----

MIIEADCCA6qgAwIBAgIKCjOOoQAAAAAAdDANBgkqhkiG9w0BAQUFADCBkDEgMB4G

CSqGSIb3DQEJARYRYW1hbmRrZUBjaXNjby5jb20xCzAJBgNVBAYTAklOMRIwEAYD

VQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdhbG9yZTEOMAwGA1UEChMFQ2lz

Y28xEzARBgNVBAsTCm5ldHN0b3JhZ2UxEjAQBgNVBAMTCUFwYXJuYSBDQTAeFw0w

NTExMTIwMzAyNDBaFw0wNjExMTIwMzEyNDBaMBwxGjAYBgNVBAMTEVZlZ2FzLTEu

Y2lzY28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/GNVACdjQu41C

dQ1WkjKjSICdpLfK5eJSmNCQujGpzcuKsZPFXjF2UoiyeCYE8ylncWyw5E08rJ47

glxr42/sI9IRIb/8udU/cj9jSSfKK56koa7xWYAu8rDfz8jMCnIM4W1aY/q2q4Gb

x7RifdV06uFqFZEgs17/Elash9LxLwIDAQABo4ICEzCCAg8wJQYDVR0RAQH/BBsw

GYIRVmVnYXMtMS5jaXNjby5jb22HBKwWH6IwHQYDVR0OBBYEFKCLi+2sspWEfgrR

bhWmlVyo9jngMIHMBgNVHSMEgcQwgcGAFCco8kaDG6wjTEVNjskYUBoLFmxxoYGW

pIGTMIGQMSAwHgYJKoZIhvcNAQkBFhFhbWFuZGtlQGNpc2NvLmNvbTELMAkGA1UE

BhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQ4w

DAYDVQQKEwVDaXNjbzETMBEGA1UECxMKbmV0c3RvcmFnZTESMBAGA1UEAxMJQXBh

cm5hIENBghAFYNKJrLQZlE9JEiWMrRl6MGsGA1UdHwRkMGIwLqAsoCqGKGh0dHA6

Ly9zc2UtMDgvQ2VydEVucm9sbC9BcGFybmElMjBDQS5jcmwwMKAuoCyGKmZpbGU6

Ly9cXHNzZS0wOFxDZXJ0RW5yb2xsXEFwYXJuYSUyMENBLmNybDCBigYIKwYBBQUH

AQEEfjB8MDsGCCsGAQUFBzAChi9odHRwOi8vc3NlLTA4L0NlcnRFbnJvbGwvc3Nl

LTA4X0FwYXJuYSUyMENBLmNydDA9BggrBgEFBQcwAoYxZmlsZTovL1xcc3NlLTA4

XENlcnRFbnJvbGxcc3NlLTA4X0FwYXJuYSUyMENBLmNydDANBgkqhkiG9w0BAQUF

AANBADbGBGsbe7GNLh9xeOTWBNbm24U69ZSuDDcOcUZUUTgrpnTqVpPyejtsyflw

E36cIZu4WsExREqxbTk8ycx7V5o=

-----END CERTIFICATE-----

Vegas-1(config)# exit

Vegas-1#

Step 11 Verify the certificate configuration.

Vegas-1# show crypto ca certificates

Trustpoint: myCA

certificate:

subject= /CN=Vegas-1.cisco.com

issuer= /emailAddress=admin@yourcompany.com/C=IN/ST=Karnataka/L=Bangalore/O=Cisco/OU

=netstorage/CN=Aparna CA

serial=0A338EA1000000000074

notBefore=Nov 12 03:02:40 2005 GMT

notAfter=Nov 12 03:12:40 2006 GMT

MD5 Fingerprint=3D:33:62:3D:B4:D0:87:A0:70:DE:A3:87:B3:4E:24:BF

purposes: sslserver sslclient ike

CA certificate 0:

subject= /emailAddress=admin@yourcompany.com/C=IN/ST=Karnataka/L=Bangalore/O=Yourcompany/O

U=netstorage/CN=Aparna CA

issuer= /emailAddress=admin@yourcompany.com/C=IN/ST=Karnataka/L=Bangalore/O=Yourcompany/OU

=netstorage/CN=Aparna CA

serial=0560D289ACB419944F4912258CAD197A

notBefore=May 3 22:46:37 2005 GMT

notAfter=May 3 22:55:17 2007 GMT

MD5 Fingerprint=65:84:9A:27:D5:71:03:33:9C:12:23:92:38:6F:78:12

purposes: sslserver sslclient ike

Step 12 Save the certificate configuration to the startup configuration.

Vegas-1# copy running-config startup-config

To configure certificates on an MDS switch, follow these steps:

Step 1 Choose Switches and set the LogicalName field to configure the switch host name.

Step 2 Choose Switches > Interfaces > Management > DNS and set the DefaultDomainName field to configure.

Step 3 To create an RSA key-pair for the switch, follow these steps:

a. Choose Switches > Security > PKI and select the RSA Key-Pair tab.

b. Click Create Row and set the name and size field.

c. Check the Exportable check box and click Create.

Step 4 To create a trust point and associate the RSA key-pairs with it, follow these steps:

a. Choose Switches > Security > PKI and select the Trustpoints tab.

b. Click Create Row and set the TrustPointName field.

c. Select the RSA key-pairs from the KeyPairName drop-down menu.

d. Select the certificates revocation method from the CARevoke drop-down menu.

e. Click Create.

Step 5 Choose Switches > Copy Configuration and click Apply Changes to copy the running to startup configuration and save the trustpoint and key pair.

Step 6 Download the CA certificate from the CA that you want to add as the trustpoint CA.

Step 7 To authenticate the CA that you want to enroll to the trust point, follow these steps:.

a. Using Device Manager, choose Admin > Flash Files and select Copy and tftp copy the CA certificate to bootflash.

b. Using DCNM-SAN, choose Switches > Security > PKI and select the TrustPoint Actions tab.

c. Select cauth from the Command drop-down menu.

d. Click ... in the URL field and select the CA certificate from bootflash.

e. Click Apply Changes to authenticate the CA that you want to enroll to the trust point.

tab in the Information Pane.

trust point action.

.

.

Step 8 To generate a certificate request for enrolling with that trust point, follow these steps:

tab in the Information pane.

from the Command drop-down menu. This generates a PKCS#10 certificate signing request (CSR) needed for an identity certificate from the CA corresponding to this trust point entry.

c. Enter the output file name for storing the generated certificate request. It should be specified in the bootflash:filename format and will be used to store the CSR generated in PEM format.

password to be included in the CSR. The challenge password is not saved with the configuration. This password is required in the event that your certificate needs to be revoked, so you must remember this password.

to save the changes.

Step 9 Request an identity certificate from the CA.

Note The CA may require manual verification before issuing the identity certificate.

Step 10 To import the identity certificate, follow these steps:

a. Using Device Manager, choose Admin > Flash Files and select Copy and use TFTP to copy the CA certificate to bootflash.

b. Using DCNM-SAN, choose Switches > Security > PKI and click the TrustPoint Actions tab.

option from the Command drop-down menu to import an identity certificate in this trust point.

Note The identity certificate should be available in PEM format in a file in bootflash.

d. Enter the name of the certificate file which was copied to bootflash, in the URL field in the bootflash:filename format.

If successful, the values of the identity certificate and its related objects, like the certificate file name, are automatically updated with the appropriate values as per the corresponding attributes in the identity certificate.

Downloading a CA Certificate

To download a CA certificate from the Microsoft Certificate Services web interface, follow these steps:

.

link.

button in the File Download dialog box.

.

.

.

button on the Certificate Export Wizard dialog box.

command.

Requesting an Identity Certificate

To request an identify certificate from a Microsoft Certificate server using a PKCS#10 certificate signing request (CRS), follow these steps:

.

.

.

.

The certificate request is copied from the MDS switch console (see the “Generating Certificate Requests” section and “Configuring Certificates on the MDS Switch” section).

Step 5 Wait one or two days until the certificate is issued by the CA administrator.

Step 6 The CA administrator approves the certificate request.

.

.

link.

on the File Download dialog box.

.

.

.

command.

Revoking a Certificate

To revoke a certificate using the Microsoft CA administrator program, follow these steps:

folder on the Certification Authority tree. From the list, right-click the certificate you want to revoke.

.

.

folder to list and verify the certificate revocation.

Generating and Publishing the CRL

To generate and publish the CRL using the Microsoft CA administrator program, follow these steps:

on the Certification Authority screen.

on the Certificate Revocation List dialog box to publish the latest CRL.

Downloading the CRL

To download the CRL from the Microsoft CA website, follow these steps:

.

link.

in the File Download dialog box.

.

command.

Importing the CRL

To import the CRL to the trust point corresponding to the CA, follow these steps:

Step 1 Copy the CRL file to the MDS switch bootflash.

Vegas-1# copy tftp:apranaCA.crl bootflash:aparnaCA.crl

Step 2 Configure the CRL.

Vegas-1# config t

Vegas-1(config)# crypto ca crl request myCA bootflash:aparnaCA.crl

Vegas-1(config)#

Step 3 Display the contents of the CRL.

Vegas-1(config)# do sh crypto ca crl myCA

Trustpoint: myCA

CRL:

Certificate Revocation List (CRL):

Version 2 (0x1)

Signature Algorithm: sha1WithRSAEncryption

Issuer: /emailAddress=admin@yourcompany.com/C=IN/ST=Karnatak

Yourcompany/OU=netstorage/CN=Aparna CA

Last Update: Nov 12 04:36:04 2005 GMT

Next Update: Nov 19 16:56:04 2005 GMT

CRL extensions:

X509v3 Authority Key Identifier:

keyid:27:28:F2:46:83:1B:AC:23:4C:45:4D:8E:C9:18:50:1

1.3.6.1.4.1.311.21.1:

...

Revoked Certificates:

Serial Number: 611B09A1000000000002

Revocation Date: Aug 16 21:52:19 2005 GMT

Serial Number: 4CDE464E000000000003

Revocation Date: Aug 16 21:52:29 2005 GMT

Serial Number: 4CFC2B42000000000004

Revocation Date: Aug 16 21:52:41 2005 GMT

Serial Number: 6C699EC2000000000005

Revocation Date: Aug 16 21:52:52 2005 GMT

Serial Number: 6CCF7DDC000000000006

Revocation Date: Jun 8 00:12:04 2005 GMT

Serial Number: 70CC4FFF000000000007

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 4D9B1116000000000008

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 52A80230000000000009

Revocation Date: Jun 27 23:47:06 2005 GMT

CRL entry extensions:

X509v3 CRL Reason Code:

CA Compromise

Serial Number: 5349AD4600000000000A

Revocation Date: Jun 27 23:47:22 2005 GMT

CRL entry extensions:

X509v3 CRL Reason Code:

CA Compromise

Serial Number: 53BD173C00000000000B

Revocation Date: Jul 4 18:04:01 2005 GMT

CRL entry extensions:

X509v3 CRL Reason Code:

Certificate Hold

Serial Number: 591E7ACE00000000000C

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 5D3FD52E00000000000D

Revocation Date: Jun 29 22:07:25 2005 GMT

CRL entry extensions:

X509v3 CRL Reason Code:

Key Compromise

Serial Number: 5DAB771300000000000E

Revocation Date: Jul 14 00:33:56 2005 GMT

Serial Number: 5DAE53CD00000000000F

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 5DB140D3000000000010

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 5E2D7C1B000000000011

Revocation Date: Jul 6 21:12:10 2005 GMT

CRL entry extensions:

X509v3 CRL Reason Code:

Cessation Of Operation

Serial Number: 16DB4F8F000000000012

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 261C3924000000000013

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 262B5202000000000014

Revocation Date: Jul 14 00:33:10 2005 GMT

Serial Number: 2634C7F2000000000015

Revocation Date: Jul 14 00:32:45 2005 GMT

Serial Number: 2635B000000000000016

Revocation Date: Jul 14 00:31:51 2005 GMT

Serial Number: 26485040000000000017

Revocation Date: Jul 14 00:32:25 2005 GMT

Serial Number: 2A276357000000000018

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 3F88CBF7000000000019

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 6E4B5F5F00000000001A

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 725B89D800000000001B

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 735A887800000000001C

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 148511C700000000001D

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 14A7170100000000001E

Revocation Date: Aug 16 21:53:15 2005 GMT

Serial Number: 14FC45B500000000001F

Revocation Date: Aug 17 18:30:42 2005 GMT

Serial Number: 486CE80B000000000020

Revocation Date: Aug 17 18:30:43 2005 GMT

Serial Number: 4CA4A3AA000000000021

Revocation Date: Aug 17 18:30:43 2005 GMT

Serial Number: 1AA55C8E00000000002F

Revocation Date: Sep 5 17:07:06 2005 GMT

Serial Number: 3F0845DD00000000003F

Revocation Date: Sep 8 20:24:32 2005 GMT

Serial Number: 3F619B7E000000000042

Revocation Date: Sep 8 21:40:48 2005 GMT

Serial Number: 6313C463000000000052

Revocation Date: Sep 19 17:37:18 2005 GMT

Serial Number: 7C3861E3000000000060

Revocation Date: Sep 20 17:52:56 2005 GMT

Serial Number: 7C6EE351000000000061

Revocation Date: Sep 20 18:52:30 2005 GMT

Serial Number: 0A338EA1000000000074 <-- Revoked identity certificate

Revocation Date: Nov 12 04:34:42 2005 GMT

Signature Algorithm: sha1WithRSAEncryption

0b:cb:dd:43:0a:b8:62:1e:80:95:06:6f:4d:ab:0c:d8:8e:32:

44:8e:a7:94:97:af:02:b9:a6:9c:14:fd:eb:90:cf:18:c9:96:

29:bb:57:37:d9:1f:d5:bd:4e:9a:4b:18:2b:00:2f:d2:6e:c1:

1a:9f:1a:49:b7:9c:58:24:d7:72

To import the CRL to the trust point corresponding to the CA, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

option from the Command drop-down menu to import the CRL to the selected trust point.

Step 4 Enter the input file name with the CRL in the bootflash:filename format, in the URL field.

to save the changes.

Note The identity certificate for the switch that was revoked (serial number 0A338EA1000000000074) is listed at the end.

Configuring IPsec Network Security

IP security (IPsec) protocol is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. It is developed by the Internet Engineering Task Force (IETF). IPsec provides security services at the IP layer, including protecting one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. The overall IPsec implementation is the latest version of RFC 2401. Cisco NX-OS IPsec implements RFC 2402 through RFC 2410.

IPsec uses the Internet Key Exchange (IKE) protocol to handle protocol and algorithm negotiation and to generate the encryption and authentication keys used by IPsec. While IKE can be used with other protocols, its initial implementation is with the IPsec protocol. IKE provides authentication of the IPsec peers, negotiates IPsec security associations, and establishes IPsec keys. IKE uses RFCs 2408, 2409, 2410, and 2412, and additionally implements the draft-ietf-ipsec-ikev2-16.txt draft.

The term IPsec is sometimes used to describe the entire protocol of IPsec data services and IKE security protocols and is other times used to describe only the data services.

This chapter includes the following topics:

- Information About IPsec Network Security

- Prerequisites for IPsec

- Guidelines and Limitations

- Default Settings

- Enabling IPsec Using FCIP Wizard

- Configuring IPsec and IKE Manually

- Configuring Crypto

- Verifying IPsec Configuration

- Configuration Examples for IPsec

- Field Descriptions for IPsec

Information About IPsec Network Security

IP security (IPsec) protocol is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. It is developed by the Internet Engineering Task Force (IETF). IPsec provides security services at the IP layer, including protecting one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. The overall IPsec implementation is the latest version of RFC 2401. Cisco NX-OS IPsec implements RFC 2402 through RFC 2410.

IPsec uses the Internet Key Exchange (IKE) protocol to handle protocol and algorithm negotiation and to generate the encryption and authentication keys used by IPsec. While IKE can be used with other protocols, its initial implementation is with the IPsec protocol. IKE provides authentication of the IPsec peers, negotiates IPsec security associations, and establishes IPsec keys. IKE uses RFCs 2408, 2409, 2410, and 2412, and additionally implements the draft-ietf-ipsec-ikev2-16.txt draft.

IPsec provides security for transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices (peers).

Note IPsec is not supported by the Cisco Fabric Switch for HP c-Class BladeSystem and the Cisco Fabric Switch for IBM BladeCenter.

IPsec provides security for transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices (peers).

IPsec provides the following network security services. In general, the local security policy dictates the use of one or more of these services between two participating IPsec devices:

- Data confidentiality—The IPsec sender can encrypt packets before transmitting them across a network.

- Data integrity—The IPsec receiver can authenticate packets sent by the IPsec sender to ensure that the data has not been altered during transmission.

- Data origin authentication—The IPsec receiver can authenticate the source of the IPsec packets sent. This service is dependent upon the data integrity service.

- Anti-replay protection—The IPsec receiver can detect and reject replayed packets.

Note The term data authentication is generally used to mean data integrity and data origin authentication. Within this chapter it also includes anti-replay services, unless otherwise specified.

With IPsec, data can be transmitted across a public network without fear of observation, modification, or spoofing. This enables applications such as Virtual Private Networks (VPNs), including intranets, extranets, and remote user access.

IPsec as implemented in Cisco NX-OS software supports the Encapsulating Security Payload (ESP) protocol. This protocol encapsulates the data to be protected and provides data privacy services, optional data authentication, and optional anti-replay services.

Note The Encapsulating Security Payload (ESP) protocol is a header inserted into an existing TCP/IP packet, the size of which depends on the actual encryption and authentication algorithms negotiated. To avoid fragmentation, the encrypted packet fits into the interface maximum transmission unit (MTU). The path MTU calculation for TCP takes into account the addition of ESP headers, plus the outer IP header in tunnel mode, for encryption. The MDS switches allow 100 bytes for packet growth for IPsec encryption.

Note When using IPsec and IKE, each Gigabit Ethernet interface on the IPS module (either on 14+2 LC or 18+4 LC) must be configured in its own IP subnet. If there are multiple Gigabit Ethernet interfaces configured with IP address or network-mask in the same IP subnet, IKE packets may not be sent to the right peer and thus IPsec tunnel will not come up.

Figure 7-1 shows different IPsec scenarios.

Figure 7-1 FCIP and iSCSI Scenarios Using MPS-14/2 Modules

This section includes the following topics:

- About IKE

- IPsec Compatibility

- IPsec and IKE Terminology

- Supported IPsec Transforms and Algorithms

- Supported IKE Transforms and Algorithms

- About IPsec Digital Certificate Support

- About IKE Initialization

- About the IKE Domain

- About IKE Tunnels

- About IKE Policy Negotiation

- Optional IKE Parameter Configuration

- About Crypto IPv4-ACLs

- About Transform Sets in IPsec

- About Crypto Map Entries

- About SA Lifetime Negotiation

- About the AutoPeer Option

- About Perfect Forward Secrecy

- About Crypto Map Set Interface Application

- IPsec Maintenance

- Global Lifetime Values

About IKE

IKE automatically negotiates IPsec security associations and generates keys for all switches using the IPsec feature. Specifically, IKE provides these benefits:

- Allows you to refresh IPsec SAs.

- Allows IPsec to provide anti-replay services.

- Supports a manageable, scalable IPsec configuration.

- Allows dynamic authentication of peers.

IKE is not supported on the Cisco Fabric Switch for HP c-Class BladeSystem and the Cisco Fabric Switch for IBM BladeSystem.

IPsec Compatibility

IPsec features are compatible with the following Cisco MDS 9000 Family hardware:

- Cisco 18/4-port Multi-Service Module (MSM-18/4) modules and MDS 9222i Module-1 modules.

- Cisco 14/2-port Multiprotocol Services (MPS-14/2) modules in Cisco MDS 9200 Switches or Cisco MDS 9500 Directors

- Cisco MDS 9216i Switch with the 14/2-port multiprotocol capability in the integrated supervisor module. Refer to the Cisco MDS 9200 Series Hardware Installation Guide for more information on the Cisco MDS 9216i Switch.

- The IPsec feature is not supported on the management interface.

IPsec features are compatible with the following fabric setup:

- Two connected Cisco MDS 9200 Switches or Cisco MDS 9500 Directors running Cisco MDS SAN-OS Release 2.0(1b) or later, or Cisco NX-OS Release 4.1(1).

- A Cisco MDS 9200 Switches or Cisco MDS 9500 Directors running Cisco MDS SAN-OS Release 2.0(1b) or later, or Cisco NX-OS Release 4.1(1) connected to any IPsec compliant device.

- The following features are not supported in the Cisco NX-OS implementation of the IPsec feature:

– Authentication Header (AH)

– Transport mode

– Security association bundling

– Manually configuring security associations

– Per host security association option in a crypto map

– Security association idle timeout

– Dynamic crypto maps

Note Any reference to crypto maps in this document, only refers to static crypto maps.

IPsec and IKE Terminology

The terms used in this chapter are explained in this section.

- Security association (SA)— An agreement between two participating peers on the entries required to encrypt and decrypt IP packets. Two SAs are required for each peer in each direction (inbound and outbound) to establish bidirectional communication between the peers. Sets of bidirectional SA records are stored in the SA database (SAD). IPsec uses IKE to negotiate and bring up SAs. Each SA record includes the following information:

– Security parameter index (SPI)—A number which, together with a destination IP address and security protocol, uniquely identifies a particular SA. When using IKE to establish the SAs, the SPI for each SA is a pseudo-randomly derived number.

– Peer—A switch or other device that participates in IPsec. For example, a Cisco MDS switch or other Cisco routers that support IPsec.

– Transform—A list of operations done to provide data authentication and data confidentiality. For example, one transform is the ESP protocol with the HMAC-MD5 authentication algorithm.

– Session key—The key used by the transform to provide security services.

– Lifetime—A lifetime counter (in seconds and bytes) is maintained from the time the SA is created. When the time limit expires the SA is no longer operational and, if required, is automatically renegotiated (rekeyed).

The–isco NX-OS implementation of IPsec does not support transport mode.

Note The term tunnel mode is different from the term tunnel, which is used to indicate a secure communication path between two peers, such as two switches connected by an FCIP link.

- Anti-replay—A security service where the receiver can reject old or duplicate packets to protect itself against replay attacks. IPsec provides this optional service by use of a sequence number combined with the use of data authentication.

- Data authentication—Data authentication can refer either to integrity alone or to both integrity and authentication (data origin authentication is dependent on data integrity).

– Data integrity—Verifies that data has not been altered.

– Data origin authentication—Verifies that the data was actually sent by the claimed sender.

- Data confidentiality—A security service where the protected data cannot be observed.

- Data flow—A grouping of traffic, identified by a combination of source address and mask or prefix, destination address mask or prefix length, IP next protocol field, and source and destination ports, where the protocol and port fields can have any of these values. Traffic matching a specific combination of these values is logically grouped together into a data flow. A data flow can represent a single TCP connection between two hosts, or it can represent traffic between two subnets. IPsec protection is applied to data flows.

- Perfect forward secrecy (PFS)—A cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys.

- Security Policy Database (SPD)—An ordered list of policies applied to traffic. A policy decides if a packet requires IPsec processing, if it should be allowed in clear text, or if it should be dropped.

– The IPsec SPDs are derived from user configuration of crypto maps.

– The IKE SPD is configured by the user.

Supported IPsec Transforms and Algorithms

The component technologies implemented for IPsec include the following transforms:

- Advanced Encrypted Standard (AES) is an encryption algorithm. It implements either 128 or 256 bits using Cipher Block Chaining (CBC) or counter mode.

- Data Encryption Standard (DES) is used to encrypt packet data and implements the mandatory 56-bit DES-CBC. CBC requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPsec packet.

- Triple DES (3DES) is a stronger form of DES with 168-bit encryption keys that allow sensitive information to be transmitted over untrusted networks.

Note Cisco NX-OS images with strong encryption are subject to United States government export controls, and have a limited distribution. Images to be installed outside the United States require an export license. Customer orders might be denied or subject to delay due to United States government regulations. Contact your sales representative or distributor for more information, or send e-mail to export@cisco.com.

- Message Digest 5 (MD5) is a hash algorithm with the HMAC variant. HMAC is a keyed hash variant used to authenticate data.

- Secure Hash Algorithm (SHA-1) is a hash algorithm with the Hash Message Authentication Code (HMAC) variant.

- AES-XCBC-MAC is a Message Authentication Code (MAC) using the AES algorithm.

Supported IKE Transforms and Algorithms

The component technologies implemented for IKE include the following transforms:

- Diffie-Hellman (DH) is a public-key cryptography protocol that allows two parties to establish a shared secret over an unsecure communications channel. Diffie-Hellman is used within IKE to establish session keys. Group 1 (768-bit), Group 2 (1024-bit), and Group 5 (1536-bit) are supported.

- Advanced Encrypted Standard (AES) is an encryption algorithm. It implements either 128 bits using Cipher Block Chaining (CBC) or counter mode.

- Data Encryption Standard (DES) is used to encrypt packet data and implements the mandatory 56-bit DES-CBC. CBC requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPsec packet.

- Triple DES (3DES) is a stronger form of DES with 168-bit encryption keys that allow sensitive information to be transmitted over untrusted networks.

Note Cisco NX-OS images with strong encryption are subject to United States government export controls, and have a limited distribution. Images to be installed outside the United States require an export license. Customer orders might be denied or subject to delay due to United States government regulations. Contact your sales representative or distributor for more information, or send e-mail to export@cisco.com.

- Message Digest 5 (MD5) is a hash algorithm with the HMAC variant. HMAC is a keyed hash variant used to authenticate data.

- Secure Hash Algorithm (SHA-1) is a hash algorithm with the Hash Message Authentication Code (HMAC) variant.

- The switch authentication algorithm uses the preshared keys based on the IP address

About IPsec Digital Certificate Support

This section describes the advantages of using certificate authorities (CAs) and digital certificates for authentication.

Implementing IPsec Without CAs and Digital Certificates

Without a CA and digital certificates, enabling IPsec services (such as encryption) between two Cisco MDS switches requires that each switch has the key of the other switch (such as an RSA public key or a shared key). You must manually specify either the RSA public keys or preshared keys on each switch in the fabric using IPsec services. Also, each new device added to the fabric will require manual configuration of the other switches in the fabric to support secure communication. Each (see Figure 7-2) switch uses the key of the other switch to authenticate the identity of the other switch; this authentication always occurs when IPsec traffic is exchanged between the two switches.

If you have multiple Cisco MDS switches in a mesh topology and want to exchange IPsec traffic passing among all of those switches, you must first configure shared keys or RSA public keys among all of those switches.

Figure 7-2 Two IPsec Switches Without CAs and Digital Certificates

Every time a new switch is added to the IPsec network, you must configure keys between the new switch and each of the existing switches. (In Figure 7-3, four additional two-part key configurations are required to add a single encrypting switch to the network).

Consequently, the more devices that require IPsec services, the more involved the key administration becomes. This approach does not scale well for larger, more complex encrypting networks.

Figure 7-3 Four IPsec Switches Without a CA and Digital Certificates

Implementing IPsec with CAs and Digital Certificates

With CA and digital certificates, you do not have to configure keys between all the encrypting switches. Instead, you individually enroll each participating switch with the CA, requesting a certificate for the switch. When this has been accomplished, each participating switch can dynamically authenticate all the other participating switches. When two devices want to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, you simply enroll that device with a CA, and none of the other devices needs modification. When the new device attempts an IPsec connection, certificates are automatically exchanged and the device can be authenticated.

Figure 7-4 shows the process of dynamically authenticating the devices.

Figure 7-4 Dynamically Authenticating Devices with a CA

To add a new IPsec switch to the network, you need only configure that new switch to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPsec switches.

How CA Certificates Are Used by IPsec Devices

When two IPsec switches want to exchange IPsec-protected traffic passing between them, they must first authenticate each other—otherwise, IPsec protection cannot occur. The authentication is done with IKE.

IKE can use two methods to authenticate the switches, using preshared keys without a CA and using RSA key-pairs with a CA. Both methods require that keys must be preconfigured between the two switches.

Without a CA, a switch authenticates itself to the remote switch using either RSA-encrypted preshared keys.

With a CA, a switch authenticates itself to the remote switch by sending a certificate to the remote switch and performing some public key cryptography. Each switch must send its own unique certificate that was issued and validated by the CA. This process works because the certificate of each switch encapsulates the public key of the switch, each certificate is authenticated by the CA, and all participating switches recognize the CA as an authenticating authority. This scheme is called IKE with an RSA signature.

Your switch can continue sending its own certificate for multiple IPsec sessions, and to multiple IPsec peers until the certificate expires. When the certificate expires, the switch administrator must obtain a new one from the CA.

CAs can also revoke certificates for devices that will no longer participate in IPsec. Revoked certificates are not recognized as valid by other IPsec devices. Revoked certificates are listed in a certificate revocation list (CRL), which each peer may check before accepting a certificate from another peer.

Certificate support for IKE has the following considerations:

- The switch FQDN (host name and domain name) must be configured before installing certificates for IKE.

- Only those certificates that are configured for IKE or general usage are used by IKE.

- The first IKE or general usage certificate configured on the switch is used as the default certificate by IKE.

- The default certificate is for all IKE peers unless the peer specifies another certificate.

- If the peer asks for a certificate which is signed by a CA that it trusts, then IKE uses that certificate, if it exists on the switch, even if it is not the default certificate.

- If the default certificate is deleted, the next IKE or general usage certificate, if any exists, is used by IKE as the default certificate.

- Certificate chaining is not supported by IKE.

- IKE only sends the identity certificate, not the entire CA chain. For the certificate to be verified on the peer, the same CA chain must also exist there.

About IKE Initialization

The IKE feature must first be enabled and configured so the IPsec feature can establish data flow with the required peer. DCNM-SAN initializes IKE when you first configure it.

You cannot disable IKE if IPsec is enabled. If you disable the IKE feature, the IKE configuration is cleared from the running configuration.

About the IKE Domain

You must apply the IKE configuration to an IPsec domain to allow traffic to reach the supervisor module in the local switch. DCNM-SAN sets the IPsec domain automatically when you configure IKE.

About IKE Tunnels

An IKE tunnel is a secure IKE session between two endpoints. IKE creates this tunnel to protect IKE messages used in IPsec SA negotiations.

Two versions of IKE are used in the Cisco NX-OS implementation.

- IKE version 1 (IKEv1) is implemented using RFC 2407, 2408, 2409, and 2412.

- IKE version 2 (IKEv2) is a simplified and more efficient version and does not interoperate with IKEv1. IKEv2 is implemented using the draft-ietf-ipsec-ikev2-16.txt draft.

About IKE Policy Negotiation

To protect IKE negotiations, each IKE negotiation begins with a common (shared) IKE policy. An IKE policy defines a combination of security parameters to be used during the IKE negotiation. By default, no IKE policy is configured. You must create IKE policies at each peer. This policy states which security parameters will be used to protect subsequent IKE negotiations and mandates how peers are authenticated. You can create multiple, prioritized policies at each peer to ensure that at least one policy will match a remote peer's policy.

You can configure the policy based on the encryption algorithm (DES, 3DES, or AES), the hash algorithm (SHA or MD5), and the DH group (1, 2, or 5). Each policy can contain a different combination of parameter values. A unique priority number identifies the configured policy. This number ranges from 1 (highest priority) to 255 (lowest priority). You can create multiple policies in a switch. If you need to connect to a remote peer, you must ascertain that at least one policy in the local switch contains the identical parameter values configured in the remote peer. If several policies have identical parameter configurations, the policy with the lowest number is selected.

provides a list of allowed transform combinations.

Table 7-1 IKE Transform Configuration Parameters

Parameter

Accepted Values

Keyword

Default Value

encryption algorithm

56-bit DES-CBC

168-bit DES

128-bit AES

hash algorithm

SHA-1 (HMAC variant)

MD5 (HMAC variant)

authentication method

Preshared keys

Not configurable

Preshared keys

DH group identifier

768-bit DH

1024-bit DH

1536-bit DH

5

The following table lists the supported and verified settings for IPsec and IKE encryption authentication algorithms on the Microsoft Windows and Linux platforms:

Platform

IKE

IPsec

Microsoft iSCSI initiator, Microsoft IPsec implementation on Microsoft Windows 2000 platform

DH group 2

3DES, SHA-1

Free Swan IPsec implementation on Linux platform

3DES, MD5, DH group 1

3DES, MD5

Note When you configure the hash algorithm, the corresponding HMAC version is used as the authentication algorithm.

When the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the other peer's received policies. The remote peer checks each of its policies in order of its priority (highest priority first) until a match is found.

A match is found when the two peers have the same encryption, hash algorithm, authentication algorithm, and DH group values. If a match is found, IKE completes the security negotiation and the IPsec SAs are created.

If an acceptable match is not found, IKE refuses negotiation and the IPsec data flows will not be established.

Optional IKE Parameter Configuration

You can optionally configure the following parameters for the IKE feature:

- The lifetime association within each policy—The lifetime ranges from 600 to 86,400 seconds. The default is 86,400 seconds (equals one day). The lifetime association within each policy is configured when you are creating an IKE policy. See the “Configuring an IKE Policy” section.

- The keepalive time for each peer if you use IKEv2—The keepalive ranges from 120 to 86,400 seconds. The default is 3,600 seconds (equals one hour).

- The initiator version for each peer—IKE v1 or IKE v2 (default). Your choice of initiator version does not affect interoperability when the remote device initiates the negotiation. Configure this option if the peer device supports IKEv1 and you can play the initiator role for IKE with the specified device. Use the following considerations when configuring the initiator version with FCIP tunnels:

– If the switches on both sides of an FCIP tunnel are running MDS SAN-OS Release 3.0(1) or later, or Cisco NX-OS 4.1(1) you must configure initiator version IKEv1 on both sides of an FCIP tunnel to use only IKEv1. If one side of an FCIP tunnel is using IKEv1 and the other side is using IKEv2, the FCIP tunnel uses IKEv2.

– If the switch on one side of an FCIP tunnel is running MDS SAN-OS Release 3.0(1) or later, or Cisco NX-OS 4.1(1b) and the switch on the other side of the FCIP tunnel is running MDS SAN-OS Release 2.x, configuring IKEv1 on either side (or both) results in the FCIP tunnel using IKEv1.

Note Only IKE v1 is supported to build IPsec between 2.x and 3.x MDS switches.

Caution You may need to configure the initiator version even when the switch does not behave as an IKE initiator under normal circumstances. Always using this option guarantees a faster recovery of traffic flows in case of failures.

Tip The keepalive time only applies to IKEv2 peers and not to all peers.

Note When IPsec implementations in the host prefer to initiate the IPsec rekey, be sure to configure the IPsec lifetime value in the Cisco MDS switch to be higher than the lifetime value in the host.

About Crypto IPv4-ACLs

IP access control lists (IPv4-ACLs) provide basic network security to all switches in the Cisco MDS 9000 Family. IPv4 IP-ACLs restrict IP-related traffic based on the configured IP filters. See Chapter 5, “Configuring IPv4 and IPv6 Access Control Lists” for details on creating and defining IPv4-ACLs.

In the context of crypto maps, IPv4-ACLs are different from regular IPv4-ACLs. Regular IPv4-ACLs determine what traffic to forward or block at an interface. For example, IPv4-ACLs can be created to protect all IP traffic between subnet A and subnet Y or Telnet traffic between host A and host B.

Crypto IPv4-ACLs are used to define which IP traffic requires crypto protection and which traffic does not.

Crypto IPv4-ACLs associated with IPsec crypto map entries have four primary functions:

- Select outbound traffic to be protected by IPsec (permit = protect).

- Indicate the data flow to be protected by the new SAs (specified by a single permit entry) when initiating negotiations for IPsec SAs.

- Process inbound traffic to filter out and discard traffic that should have been protected by IPsec.

- Determine whether or not to accept requests for IPsec SAs on behalf of the requested data flows when processing IKE negotiation from the IPsec peer.

Tip If you want some traffic to receive one type of IPsec protection (for example, encryption only) and other traffic to receive a different type of IPsec protection (for example, both authentication and encryption), create two IPv4-ACLs. Use both IPv4-ACLs in different crypto maps to specify different IPsec policies.

Note IPsec does not support IPv6-ACLs.

Mirror Image Crypto IPv4-ACLs

For every crypto IPv4-ACL specified for a crypto map entry defined at the local peer, define a mirror image crypto IPv4-ACL at the remote peer. This configuration ensures that IPsec traffic applied locally can be processed correctly at the remote peer.

Tip The crypto map entries themselves must also support common transforms and must refer to the other system as a peer.

Figure 7-5 shows some sample scenarios with and without mirror image IPv4-ACLs.

Figure 7-5 IPsec Processing of Mirror Image Configuration

As Figure 7-5 indicates, IPsec SAs can be established as expected whenever the two peers' crypto IPv4-ACLs are mirror images of each other. However, an IPsec SA can be established only some of the time when the IPv4-ACLs are not mirror images of each other. This can happen in the case when an entry in one peer's IPv4-ACL is a subset of an entry in the other peer's IPv4-ACL, such as shown in cases 3 and 4 of Figure 7-5. IPsec SA establishment is critical to IPsec. Without SAs, IPsec does not work, causing any packets matching the crypto IPv4-ACL criteria to be silently dropped instead of being forwarded with IPsec security.

In case 4, an SA cannot be established because SAs are always requested according to the crypto IPv4-ACLs at the initiating packet's end. In case 4, router N requests that all traffic between subnet X and subnet Y be protected, but this is a superset of the specific flows permitted by the crypto IPv4-ACL at switch M so the request is not permitted. Case 3 works because switch M's request is a subset of the specific flows permitted by the crypto IPv4-ACL at router N.

Because of the complexities introduced when crypto IPv4-ACLs are not configured as mirror images at peer IPsec devices, we strongly encourage you to use mirror image crypto IPv4-ACLs.

The any Keyword in Crypto IPv4-ACLs

Tip We recommend that you configure mirror image crypto IPv4-ACLs for use by IPsec and that you avoid using the any option.

keyword in a permit statement is discouraged when you have multicast traffic flowing through the IPsec interface. This configuration can cause multicast traffic to fail.

statement causes all outbound traffic to be protected (and all protected traffic sent to the peer specified in the corresponding crypto map entry) and requires protection for all inbound traffic. Then, all inbound packets that lack IPsec protection are silently dropped, including packets for routing protocols, NTP, echo, echo response, and so forth.

in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

About Transform Sets in IPsec

A transform set represents a certain combination of security protocols and algorithms. During the IPsec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPsec security association negotiation to protect the data flows specified by that crypto map entry's access list.

During IPsec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and applied to the protected traffic as part of both peers' IPsec security associations.

Tip If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change is not applied to existing security associations, but used in subsequent negotiations to establish new security associations. If you want the new settings to take effect sooner, you can clear all or part of the security association database.

Note When you enable IPsec, the Cisco NX-OS software automatically creates a default transform set (ipsec_default_tranform_set) using AES-128 encryption and SHA-1 authentication algorithms.

provides a list of allowed transform combinations for IPsec.

Table 7-2 IPsec Transform Configuration Parameters

Parameter

Accepted Values

Keyword

encryption algorithm

56-bit DES-CBC

168-bit DES

128-bit AES-CBC

128-bit AES-CTR1

256-bit AES-CBC

aes 256

256 ctr

(optional)

SHA-1 (HMAC variant)

MD5 (HMAC variant)

AES-XCBC-MAC

aes-xcbc-mac

1.If you configure the AES counter (CTR) mode, you must also configure the authentication algorithm.

1.If you configure the AES counter (CTR) mode, you must also configure the authentication algorithm.

The following table lists the supported and verified settings for IPsec and IKE encryption authentication algorithms on the Microsoft Windows and Linux platforms:

Platform

IKE

IPsec

Microsoft iSCSI initiator, Microsoft IPsec implementation on Microsoft Windows 2000 platform

DH group 2

3DES, SHA-1

Free Swan IPsec implementation on Linux platform

3DES, MD5, DH group 1

3DES, MD5

About Crypto Map Entries

Once you have created the crypto IPv4-ACLs and transform sets, you can create crypto map entries that combine the various parts of the IPsec SA, including the following:

- The traffic to be protected by IPsec (per the crypto IPv4-ACL). A crypto map set can contain multiple entries, each with a different IPv4-ACL.

- The granularity of the flow to be protected by a set of SAs.

- The IPsec-protected traffic destination (who the remote IPsec peer is).

- The local address to be used for the IPsec traffic (applying to an interface).

- The IPsec security to be applied to this traffic (selecting from a list of one or more transform sets).

- Other parameters to define an IPsec SA.

Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set.

When you apply a crypto map set to an interface, the following events occur:

- A security policy database (SPD) is created for that interface.

- All IP traffic passing through the interface is evaluated against the SPD.

If a crypto map entry sees outbound IP traffic that requires protection, an SA is negotiated with the remote peer according to the parameters included in the crypto map entry.

The policy derived from the crypto map entries is used during the negotiation of SAs. If the local switch initiates the negotiation, it will use the policy specified in the crypto map entries to create the offer to be sent to the specified IPsec peer. If the IPsec peer initiates the negotiation, the local switch checks the policy from the crypto map entries and decides whether to accept or reject the peer's request (offer).

For IPsec to succeed between two IPsec peers, both peers' crypto map entries must contain compatible configuration statements.

SA Establishment Between Peers

When two peers try to establish an SA, they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries.

For two crypto map entries to be compatible, they must at least meet the following criteria:

- The crypto map entries must contain compatible crypto IPv4-ACLs (for example, mirror image IPv4-ACLs). If the responding peer entry is in the local crypto, the IPv4-ACL must be permitted by the peer's crypto IPv4-ACL.

- The crypto map entries must each identify the other peer or must have auto peer configured.

- If you create more than one crypto map entry for a given interface, use the seq-num of each map entry to rank the map entries: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.

- The crypto map entries must have at least one transform set in common, where IKE negotiations are carried out and SAs are established. During the IPsec SA negotiation, the peers agree to use a particular transform set when protecting a particular data flow.

When a packet matches a permit entry in a particular IPv4-ACL, the corresponding crypto map entry is tagged, and the connections are established.

About SA Lifetime Negotiation

You can override the global lifetime values (size and time) by configuring an SA-specific lifetime value.

To specify SA lifetime negotiation values, you can optionally configure the lifetime value for a specified crypto map. If you do, this value overrides the globally set values. If you do not specify the crypto map specific lifetime, the global value (or global default) is used.

See the “Global Lifetime Values” section for more information on global lifetime values.

About the AutoPeer Option

in the crypto map indicates that the destination endpoint of the traffic should be used as the peer address for the SA. Using the same crypto map, a unique SA can be set up at each of the endpoints in the subnet specified by the crypto map's IPv4-ACL entry. Auto-peer simplifies configuration when traffic endpoints are IPsec capable. It is particularly useful for iSCSI, where the iSCSI hosts in the same subnet do not require separate configuration.

Figure 7-6 shows a scenario where the auto-peer option can simplify configuration. Using the auto-peer option, only one crypto map entry is needed for all the hosts from subnet X to set up SAs with the switch. Each host will set up its own SA, but will share the crypto map entry. Without the auto-peer option, each host needs one crypto map entry.

See the “Sample iSCSI Configuration” section for more details.

Figure 7-6 iSCSI with End-to-End IPsec Using the auto-peer Option

About Perfect Forward Secrecy

To specify SA lifetime negotiation values, you can also optionally configure the perfect forward secrecy (PFS) value in the crypto map.

The PFS feature is disabled by default. If you set the PFS group, you can set one of the DH groups: 1, 2, 5, or 14. If you do not specify a DH group, the software uses group 1 by default.

About Crypto Map Set Interface Application

You need to apply a crypto map set to each interface through which IPsec traffic will flow. Applying the crypto map set to an interface instructs the switch to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or SA negotiation on behalf of the traffic to be protected by crypto.

You can apply only one crypto map set to an interface. You can apply the same crypto map to multiple interfaces. However, you cannot apply more than one crypto map set to each interface.

IPsec Maintenance

Certain configuration changes will only take effect when negotiating subsequent security associations. If you want the new settings to take immediate effect, you must clear the existing security associations so that they will be reestablished with the changed configuration. If the switch is actively processing IPsec traffic, it is desirable to clear only the portion of the security association database that would be affected by the configuration changes (that is, clear only the security associations established by a given crypto map set). Clearing the full security association database should be reserved for large-scale changes, or when the router is processing very little other IPsec traffic.

Tip You can obtain the SA index from the output of the show crypto sa domain interface gigabitethernet slot/port command.

Use the following command to clear part of the SA database.

switch# clear crypto sa domain ipsec interface gigabitethernet 2/1 inbound sa-index 1

Global Lifetime Values

If you have not configured a lifetime in the crypto map entry, the global lifetime values are used when negotiating new IPsec SAs.

You can configure two lifetimes: timed or traffic-volume. An SA expires after the first of these lifetimes is reached. The default lifetimes are 3,600 seconds (one hour) and 450 GB.

If you change a global lifetime, the new lifetime value will not be applied to currently existing SAs, but will be used in the negotiation of subsequently established SAs. If you wish to use the new values immediately, you can clear all or part of the SA database.

Assuming that the particular crypto map entry does not have lifetime values configured, when the switch requests new SAs it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new SAs. When the switch receives a negotiation request from the peer, it uses the value determined by the IKE version in use:

- If you use IKEv1 to set up IPsec SAs, the SA lifetime values are chosen to be the smaller of the two proposals. The same values are programmed on both the ends of the tunnel.

- If you use IKEv2 to set up IPsec SAs, the SAs on each end have their own set up of lifetime values and thus the SAs on both sides expire independently.

The SA (and corresponding keys) will expire according to whichever comes sooner, either after the specified amount of time (in seconds) has passed or after the specified amount of traffic (in bytes) has passed.

A new SA is negotiated before the lifetime threshold of the existing SA is reached to ensure that negotiation completes before the existing SA expires.

The new SA is negotiated when one of the following thresholds is reached (whichever comes first):

- 30 seconds before the lifetime expires or

- Approximately 10% of the lifetime in bytes remain

If no traffic has passed through when the lifetime expires, a new SA is not negotiated. Instead, a new SA will be negotiated only when IPsec sees another packet that should be protected.

Prerequisites for IPsec

To use the IPsec feature, you need to perform the following tasks:

- Obtain the ENTERPRISE_PKG license (see the Cisco MDS 9000 Family NX-OS Licensing Guide).

- Configure IKE as described in the “About IKE Initialization” section.

Guidelines and Limitations

The following are the guidelines and limitations for IPsec network security:

- Crypto IPv4-ACL Guidelines

- Crypto Map Configuration Guidelines

Crypto IPv4-ACL Guidelines

Follow these guidelines when configuring IPv4-ACLs for the IPsec feature:

- The Cisco NX-OS software only allows name-based IPv4-ACLs.

- When an IPv4-ACL is applied to a crypto map, the following options apply:

– Permit—Applies the IPsec feature to the traffic.

– Deny—Allows clear text (default).

Note IKE traffic (UDP port 500) is implicitly transmitted in clear text.

- The IPsec feature only considers the source and destination IPv4 addresses and subnet masks, protocol, and single port number. There is no support for IPv6 in IPsec.

Note The IPsec feature does not support port number ranges and ignores higher port number field, if specified.

- The permit option causes all IP traffic that matches the specified conditions to be protected by crypto, using the policy described by the corresponding crypto map entry.

- The deny option prevents traffic from being protected by crypto. The first deny statement causes the traffic to be in clear text.

- The crypto IPv4-ACL you define is applied to an interface after you define the corresponding crypto map entry and apply the crypto map set to the interface.

- Different IPv4-ACLs must be used in different entries of the same crypto map set.

- Inbound and outbound traffic is evaluated against the same outbound IPv4-ACL. Therefore, the IPv4-ACL's criteria is applied in the forward direction to traffic exiting your switch, and the reverse direction to traffic entering your switch.

- Each IPv4-ACL filter assigned to the crypto map entry is equivalent to one security policy entry. The IPsec feature supports up to 120 security policy entries for each MPS-14/2 module and Cisco MDS 9216i Switch.

- IPsec protection (see Figure 7-7) is applied to traffic between switch interface S0 (IPv4 address 10.0.0.1) and switch interface S1 (IPv4 address 20.0.0.2) as the data exits switch A's S0 interface enroute to switch interface S1. For traffic from 10.0.0.1 to 20.0.0.2, the IPv4-ACL entry on switch A is evaluated as follows:

– source = IPv4 address 10.0.0.1

– dest = IPv4 address 20.0.0.2

For traffic from 20.0.0.2 to 10.0.0.1, that same IPv4-ACL entry on switch A is evaluated as follows:

– source = IPv4 address 20.0.0.2

– dest = IPv4 address 10.0.0.1

Figure 7-7 IPsec Processing of Crypto IPv4-ACLs

- If you configure multiple statements for a given crypto IPv4-ACL that is used for IPsec, the first permit statement that is matched is used to determine the scope of the IPsec SA. Later, if traffic matches a different permit statement of the crypto IPv4-ACL, a new, separate IPsec SA is negotiated to protect traffic matching the newly matched IPv4-ACL statement.

- Unprotected inbound traffic that matches a permit entry in the crypto IPv4-ACL for a crypto map entry flagged as IPsec is dropped, because this traffic was expected to be protected by IPsec.

- You can use the show ip access-lists command to view all IP-ACLs. The IP-ACLs used for traffic filtering purposes are also used for crypto.

- For IPsec to interoperate effectively with Microsoft iSCSI initiators, specify the TCP protocol and the local iSCSI TCP port number (default 3260) in the IPv4-ACL. This configuration ensures the speedy recovery of encrypted iSCSI sessions following disruptions such as Gigabit Ethernet interfaces shutdowns, VRRP switchovers, and port failures.

- The following example of a IPv4-ACL entry shows that the MDS switch IPv4 address is 10.10.10.50 and remote Microsoft host running encrypted iSCSI sessions is 10.10.10.16:

switch(config)# ip access-list aclmsiscsi2 permit tcp 10.10.10.50 0.0.0.0 range port 3260 3260 10.10.10.16 0.0.0.0

Crypto Map Configuration Guidelines

When configuring crypto map entries, follow these guidelines:

- The sequence number for each crypto map decides the order in which the policies are applied. A lower sequence number is assigned a higher priority.

- Only one IPv4-ACL is allowed for each crypto map entry (the IPv4-ACL itself can have multiple permit or deny entries).

- When the tunnel endpoint is the same as the destination address, you can use the auto-peer option to dynamically configure the peer.

- For IPsec to interoperate effectively with Microsoft iSCSI initiators, specify the TCP protocol and the local iSCSI TCP port number (default 3260) in the IPv4-ACL. This configuration ensures the speedy recovery of encrypted iSCSI sessions following disruptions such as Gigabit Ethernet interfaces shutdowns, VRRP switchovers, and port failures.

Default Settings

lists the default settings for IKE parameters.

Table 7-3 Default IKE Parameters

Parameters

Default

IKE

Disabled.

IKE version

IKE version 2.

IKE encryption algorithm

3DES.

IKE hash algorithm

SHA.

IKE authentication method

Not configurable (uses preshared Preshared keys).

IKE DH group identifier

Group 1.

IKE lifetime association

86,400 00 seconds (equals 24 hours).

IKE keepalive time for each peer (v2)

3,600 seconds (equals 1 hour).

lists the default settings for IPsec parameters.

Table 7-4 Default IPsec Parameters

Parameters

Default

IPsec

Disabled.

Applying IPsec to the traffic.

Deny—allowing clear text.

IPsec PFS

Disabled.

IPsec global lifetime (traffic-volume)

450 Gigabytes.

IPsec global lifetime (time)

3,600 seconds (one hour).

Enabling IPsec Using FCIP Wizard

DCNM-SAN simplifies the configuration of IPsec and IKE by enabling and configuring these features as part of the FCIP configuration using the FCIP Wizard.

Detailed Steps

To enable IPsec using the FCIP Wizard, follow these steps:

Step 1 Click the FCIP Wizard icon in the toolbar.

Figure 7-8 FCIP Wizard

Step 2 Choose the switches that act as end points for the FCIP link and click Next.

Note These switches must have MPS-14/2 modules installed to configure IPsec on this FCIP link.

Step 3 Choose the Gigabit Ethernet ports on each MPS-14/2 module that will form the FCIP link.

Step 4 Check the Enforce IPSEC Security check box and set IKE Auth Key (see Figure 7-9).

Figure 7-9 Enabling IPsec on an FCIP Link

Step 5 Click Next. In the Specify Tunnel Properties dialog box, you see the TCP connection characteristics.

Step 6 Set the minimum and maximum bandwidth settings and round-trip time for the TCP connections on this FCIP link. Click the Measure button to measure the round-trip time between the Gigabit Ethernet endpoints.

Step 7 Check the Enable Write Acceleration check box to enable FCIP write acceleration on this FCIP link.

Step 8 Check the Enable Optimum Compression check box to enable IP compression on this FCIP link.

Step 9 Click Next to configure the FCIP tunnel parameters.

Step 10 Set the Port VSAN for nontrunk/auto and allowed VSAN list for the trunk tunnel. Choose a Trunk Mode for this FCIP link. See the IP Services Configuration Guide, Cisco DCNM for SAN.

Step 11 Click Finish to create this FCIP link or click Cancel to exit the FCIP Wizard without creating an FCIP link.

Detailed Steps

To verify that IPsec and IKE are enabled, follow these steps:

Step 1 Expand Switches > Security and then select IPSEC in the Physical Attributes pane.

Step 2 The Control tab is the default. Verify that the switches you want to modify for IPSec are enabled in the Status column.

Step 3 Expand Switches > Security, and then select IKE in the Physical Attributes pane.

Step 4 The Control tab is the default. Verify that the switches you want to modify for IKE are enabled in the Status column.

Configuring IPsec and IKE Manually

This section describes how to manually configure IPsec and IKE.

If you are not using the FCIP Wizard, see “Enabling IPsec Using FCIP Wizard” section.

IPsec provides secure data flows between participating peers. Multiple IPsec data flows can exist between two peers to secure different data flows, with each tunnel using a separate set of SAs.

Prerequisites

After you have completed IKE configuration, configure IPsec.

Detailed Steps

To configure IPsec in each participating IPsec peer, follow these steps:

Step 1 Identify the peers for the traffic to which secure tunnels should be established.

Step 2 Configure the transform set with the required protocols and algorithms.

Step 3 Create the crypto map and apply access control lists (IPv4-ACLs), transform sets, peers, and lifetime values as applicable.

Step 4 Apply the crypto map to the required interface.

This section includes the following topics:

- Using IPsec

- “Enabling IKE” section

- “Configuring the IKE Domain” section

- Configuring an IKE Policy

- “Configuring the Lifetime Association for a Policy” section

- Configuring the Keepalive Time for a Peer

- Configuring the Initiator Version

- Clearing IKE Tunnels or Domains

- Refreshing SAs

Using IPsec

To use the IPsec feature, follow these steps:

Step 1 Obtain the ENTERPRISE_PKG license to enable IPsec for iSCSI and to enable IPsec for FCIP. See the Cisco MDS 9000 Family NX-OS Licensing Guide for more information.

Step 2 Configure IKE as described in the “Configuring IPsec and IKE Manually” section.

Note The IPsec feature inserts new headers in existing packets (see the Cisco MDS 9000 Family NX-OS IP Services Configuration Guide See IP Services Configuration Guide, Cisco DCNM for SAN for more information).

Enabling IKE

Detailed Steps

To enable IKE, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Enables the IKE feature.

Disables (default) the IKE feature.

Note You must disable IPsec before you can disable the IKE feature.

Configuring the IKE Domain

You must apply the IKE configurations to an IPsec domain to allow traffic to reach the supervisor module in the local switch.

Detailed Steps

To configure the IPsec domain, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ike-ipsec)#

Allows IKE configurations for IPsec domains.

Configuring an IKE Policy

Detailed Steps

To configure the IKE negotiation parameters, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ike-ipsec)#

Allows IPsec domains to be configured in this switch.

Step 3

Configures the identity mode for the IKE protocol to use the IP address (default).

Configures the identity mode for the IKE protocol to use the fully-qualified domain name (FQDN).

Note The FQDN is required for using RSA signatures for authentication.

).

Step 4

Associates a preshared key with the IP address of a peer.

Deletes the association of a preshared key and the IP address of a peer.

Associates a preshared key with the FQDN of a peer.

Note To use the FQDN, you must configure the switch name and domain name on the peer.

Deletes the association of a preshared key and the IP address of a peer.

Step 5

switch(config-ike-ipsec-policy)#

Specifies the policy to configure.

Deletes the specified policy.

Step 6

Configures the encryption policy.

Defaults to 3DES encryption.

Step 7

Configures the DH group.

Defaults to DH group 1.

Step 8

Configures the hash algorithm.

Defaults to SHA.

Step 9

Configures the authentication method to use the preshared key (default).

Configures the authentication method to use the RSA signature.

Note To use RSA signatures for authentication you must configure identity authentication mode using the FQDN (see Step 3).

).

To configure the IKE policy negotiation parameters, follow these steps:

Step 1 Expand Switches > Security, and then select IKE.

Step 2 Click the Policies tab.

You see the existing IKE polices in the Information pane.

Step 3 Click Create Row to create an IKE policy.

Step 4 Enter the Priority for this switch. You can enter a value from one through 255, one being the highest.

Step 5 Select appropriate values for the encryption, hash, authentication, and DHGroup fields.

Step 6 Enter the lifetime for the policy. You can enter a lifetime from 600 to 86400 seconds.

Step 7 Click Create to create this policy, or click Close to discard any unsaved changes.

Configuring the Lifetime Association for a Policy

Detailed Steps

To configure the lifetime association for each policy, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ike-ipsec)#

Allows IPsec domains to be configured in this switch.

Step 3

switch(config-ike-ipsec-policy)#

Specifies the policy to configure.

Step 4

Configures a lifetime of 6,000 seconds.

Deletes the configured lifetime value and defaults to 86,400 seconds.

Configuring the Keepalive Time for a Peer

Detailed Steps

To configure the keepalive time for each peer, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ike-ipsec)#

Allows IPsec domains to be configured in this switch.

Step 3

Configures the keepalive time for all peers to be 60,000 seconds.

Deletes the configured keepalive time and defaults to 3,600 seconds.

To configure the keepalive time for each peer, follow these steps:

Step 1 Expand Switches > Security, and then select IKE.

Step 2 Click the Global tab.

Step 3 Enter a value (in seconds) in the KeepAliveInterval (sec). The keepalive interval in seconds is used by the IKE entity on the managed device with all the peers for the DOI corresponding to this conceptual row.

to save your changes.

Configuring the Initiator Version

Detailed Steps

To configure the initiator version using IPv4, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-ike-ipsec)#

Allows IPsec domains to be configured in this switch.

Step 3

Configures the switch to use IKEv1 when initiating IKE with device 10.10.10.0

Note IKE supports IPv4 addresses, not IPv6 addresses.

Defaults to IKEv2 for the specified device.

Defaults to IKEv2 for all devices.

To configure the initiator version, follow these steps:

Step 1 Expand Switches > Security, and then select IKE.

Step 2 Click the Initiator Version tab.

You see the existing initiator versions for the peers in the Information pane.

Step 3 Click Create Row to create an initiator version.

Step 4 Select the Switches for the remote peer for which this IKE protocol initiator is configured.

Step 5 Enter the IP address of the remote peer.

IKEv1 represents the IKE protocol version used when connecting to a remote peer.

Step 6 Click Create to create this initiator version or click Close to discard any unsaved changes.

Clearing IKE Tunnels or Domains

command in EXEC mode.

switch# clear crypto ike domain ipsec sa

Caution When you delete all the SAs within a specific IKEv2 tunnel, then that IKE tunnel is automatically deleted.

command in EXEC mode.

switch# clear crypto ike domain ipsec sa 51

Caution When you delete the IKEv2 tunnel, the associated IPsec tunnel under that IKE tunnel is automatically deleted.

Detailed Steps

To clear all the IKE tunnels or domains, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

You see the IKE tunnels.

to clear the tunnel.

Refreshing SAs

command to refresh the SAs after performing IKEv2 configuration changes.

Detailed Steps

To refresh the SAs after changing the IKEv2 configuration, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

.

Configuring Crypto

This sections includes the following topics:

- “Creating Crypto IPv4-ACLs” section

- Configuring Transform Sets

- Creating Crypto Map Entries

- Setting the SA Lifetime

- Configuring Perfect Forward Secrecy

- Applying a Crypto Map Set

- Configuring Global Lifetime Values

Creating Crypto IPv4-ACLs

Detailed Steps

To create IPv4-ACLs, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Permits all IP traffic from and to the specified networks.

Note The show ip access-list command does not display the crypto map entries. Use the show crypto map command to display the associated entries.

Add permit and deny statements as appropriate (see Information About IPv4 and IPv6 Access Control Lists). Each permit and deny specifies conditions to determine which IP packets must be protected.

Configuring Transform Sets

Detailed Steps

To configure transform sets, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

to verify the allowed transform combinations.

Deletes the applied transform set.

Configures a transform set called test specifying the 3DES encryption algorithm. In this case, the default no authentication is performed.

Deletes the applied transform set.

To configure transform sets, follow these steps:

in the Physical Attributes pane.

tab in the Information pane.

.

You see the Create IPSEC dialog box shown in Figure 7-10.

Figure 7-10 Create IPSEC

Step 4 Select the switches that you want to create a transform set for in the Create Transform Set dialog box.

Step 5 Assign a name and protocol for the transform set.

to verify the allowed transform combinations.

.

Creating Crypto Map Entries

Note If the peer IP address specified in the crypto map entry is a VRRP IP address on a remote Cisco MDS switch, ensure that the IP address is created using the secondary option (see the Cisco MDS 9000 Family NX-OS IP Services Configuration Guide for more information).

Detailed Steps

To create mandatory crypto map entries, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

ips-hac1(config-crypto-map-ip)#

Places you in the crypto map configuration mode for the entry named SampleMap with 31 as its sequence number.

Deletes the specified crypto map entry.

Deletes the entire crypto map set called SampleMap.

Step 3

Names an ACL to determine which traffic should be protected and not protected by IPsec in the context of this crypto map entry.

Deletes the matched address.

Step 4

Configures a specific peer IPv4 address.

Note IKE only supports IPv4 addresses, not IPv6 addresses.

Step 5

Deletes the configured peer.

Step 6

Specifies which transform sets are allowed for the specified crypto map entry or entries. List multiple transform sets in order of priority (highest priority first).

Deletes the association of all transform sets (regardless of you specifying a transform set name).

To create mandatory crypto map entries, follow these steps:

Step 1 Expand Switches > Security, and then select IPSEC in the Physical Attributes pane.

Step 2 Click the CryptoMap Set Entry tab.

Step 3 (Optional) Click Create Row to create a crypto map entry.

Step 4 Select the switch that you want to configure or modify. If you are creating a crypto map, set the setName and priority for this crypto map.

Step 5 Select the IPv4-ACL Profile and TransformSetIdList from the drop-down list for this crypto map.

Step 6 (Optional) Check the AutoPeer check box or set the peer address if you are creating a crypto map. See the “About the AutoPeer Option”.

Step 7 Choose the appropriate PFS selection. See the “About Perfect Forward Secrecy”.

Step 8 Supply the Lifetime and LifeSize. See the “About SA Lifetime Negotiation”.

Step 9 Click Create if you are creating a crypto map, or click Apply Changes if you are modifying an existing crypto map.

Setting the SA Lifetime

Detailed Steps

To set the SA lifetime for a specified crypto map entry, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-crypto-map-ip)#

Enters crypto map configuration submode for the entry named SampleMap with 31 as its sequence number.

Step 3

Specifies an SA lifetime for this crypto map entry using different IPsec SA lifetimes than the global lifetimes for the crypto map entry.

Deletes the entry-specific configuration and reverts to the global settings.

Step 4

Configures the traffic-volume lifetime for this SA to time out after the specified amount of traffic (in gigabytes) have passed through the FCIP link using the SA. The lifetime ranges from 1 to 4095 gigabytes.

To set the SA lifetime for a specified crypto map entry, follow these steps:

Step 1 Expand Switches > Security and then select IPSEC in the Physical Attributes pane.

Step 2 Click the CryptoMap Set Entry tab.

Step 3 Scroll to the right half of the dialog box.

column.

Step 5 Click Apply Changes to save your changes.

Configuring Perfect Forward Secrecy

Detailed Steps

To configure the PFS value, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

ips-hac1(config-crypto-map-ip)#

Places you in the crypto map configuration mode for the entry named SampleMap with 31 as its sequence number.

Step 3

Specifies that IPsec should ask for PFS when requesting new SAs for this crypto map entry, or should demand PFS in requests received from the IPsec peer.

Deletes the configured DH group and reverts to the factory default of disabling PFS.

To configure the PFS value, follow these steps:

Step 1 Expand Switches > Security and then select IPSEC in the Physical Attributes pane.

Step 2 Click the CryptoMap Set Entry tab.

column select the appropriate value.

Step 4 Click Apply Changes to save your changes.

Applying a Crypto Map Set

Detailed Steps

To apply a crypto map set to an interface, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-if)#

Selects the required Gigabit Ethernet interface (and subinterface, if required) to which the IPsec crypto map is to be applied.

Step 3

Applies the crypto map set to the selected interface.

Step 4

Deletes the crypto map that is currently applied to this interface.

To apply a crypto map set to an interface, follow these steps:

Step 1 Expand Switches > Security, and then select IPSEC in the Physical Attributes pane.

Step 2 Click the Interfaces tab.

Step 3 Select the switch and interface you want to configure.

Step 4 Enter the name of the crypto map that you want to apply to this interface in the CryptomapSetName field.

Step 5 Click Create to apply the crypto map to the selected interface or click Close to exit the dialog box without applying the crypto map.

Configuring Global Lifetime Values

Detailed Steps

To configure global SA lifetimes, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Configures the global timed lifetime for IPsec SAs to time out after the specified number of seconds have passed. The global lifetime ranges from 120 to 86400 seconds.

Reverts to the factory default of 3,600 seconds.

Step 3

Configures the global traffic-volume lifetime for IPsec SAs to time out after the specified amount of traffic (in gigabytes) has passed through the FCIP link using the SA. The global lifetime ranges from 1 to 4095 gigabytes.

Configures the global traffic-volume lifetime in kilobytes. The global lifetime ranges from 2560 to 2147483647 kilobytes.

Configures the global traffic-volume lifetime in megabytes. The global lifetime ranges from 3 to 4193280 megabytes.

Reverts to the factory default of 450 GB regardless of what value is currently configured.

To configure global SA lifetimes, follow these steps:

Step 1 Choose Switches > Security, and then select IPSEC in the Physical Attributes pane.

Step 2 You see the IPsec configuration in the Information pane.

Step 3 Click the Global tab.

column.

Step 5 Click Apply Changes to save your changes.

Verifying IPsec Configuration

To display IPsec configuration information, perform one of the following tasks:

Command

Purpose

Displays the Parameters Configured for Each IKE Policy.

show crypto ike domain ipsec initiator

Displays the Initiator Configuration.

show crypto ike domain ipsec key

Displays the Key Configuration.

show crypto ike domain ipsec policy 1

Displays the Currently Established Policies for IKE.

show crypto ike domain ipsec sa

Displays the Currently Established SAs for IKE.

show ip access-list acl10

Displays Information for the Specified ACL.

show crypto transform-set domain ipsec

Displays the Transform Set Configuration.

show crypto map domain ipsec

Displays All Configured Crypto Maps.

show crypto map domain ipsec interface gigabitethernet 4/1

Displays the Crypto Map Information for a Specific Interface.

show crypto map domain ipsec tag cm100

Displays the Specified Crypto Map Information.

show crypto sad domain ipsec interface gigabitethernet 4/1

Displays SA Association for the Specified Interface.

Displays All SA Associations.

show crypto spd domain ipsec

Displays Information About the Policy Database.

show crypto spd domain ipsec interface gigabitethernet 4/2

Displays SPD Information for a Specific Interface.

show iscsi session detail

Displays Detailed iSCSI Session Information for a Specific Interface.

show interface fcip 1

Displays FCIP Information for a Specific Interface.

show crypto global domain ipsec

Displays the Global IPsec Statistics for the Switch.

show crypto global domain ipsec interface gigabitethernet 3/1

Displays the IPsec Statistics for the Specified Interface.

show crypto global domain ipsec security-association lifetime

Displays the Global SA Lifetime Values.

.

- “Displaying IKE Configurations” section

- “Displaying IPsec Configurations” section

Displaying IKE Configurations

.

Example 7-1 Displays the Parameters Configured for Each IKE Policy

switch# show crypto ike domain ipsec

keepalive 60000

Example 7-2 Displays the Initiator Configuration

switch# show crypto ike domain ipsec initiator

initiator version 1 address 1.1.1.1

initiator version 1 address 1.1.1.2

Example 7-3 Displays the Key Configuration

switch# show crypto ike domain ipsec key

key abcdefgh address 1.1.1.1

key bcdefghi address 1.1.2.1

Example 7-4 Displays the Currently Established Policies for IKE

switch# show crypto ike domain ipsec policy 1

Priority 1, auth pre-shared, lifetime 6000 secs, encryption 3des, hash md5, DH group 5

Priority 3, auth pre-shared, lifetime 86300 secs, encryption aes, hash sha1, DH group 1

Example 7-5 Displays the Currently Established SAs for IKE

switch# show crypto ike domain ipsec sa

Tunn Local Addr Remote Addr Encr Hash Auth Method Lifetime

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

1* 172.22.31.165[500] 172.22.31.166[500] 3des sha1 preshared key 86400

2 172.22.91.174[500] 172.22.91.173[500] 3des sha1 preshared key 86400

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

NOTE: tunnel id ended with * indicates an IKEv1 tunnel

Displaying IPsec Configurations

.

Example 7-6 Displays Information for the Specified ACL

switch# show ip access-list acl10

ip access-list acl10 permit ip 10.10.10.0 0.0.0.255 10.10.10.0 0.0.0.255 (0 matches)

In Example 7-6, the display output match is only displayed of an interface (not the crypto map) meets this criteria.

Example 7-7 Displays the Transform Set Configuration

switch# show crypto transform-set domain ipsec

Transform set: 3des-md5 {esp-3des esp-md5-hmac}

will negotiate {tunnel}

Transform set: des-md5 {esp-des esp-md5-hmac}

will negotiate {tunnel}

Transform set: test {esp-aes-128-cbc esp-md5-hmac}

will negotiate {tunnel}

Example 7-8 Displays All Configured Crypto Maps

switch# show crypto map domain ipsec

Crypto Map “cm10” 1 ipsec

Peer = Auto Peer

IP ACL = acl10

permit ip 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

Transform-sets: 3des-md5, des-md5,

Security Association Lifetime: 4500 megabytes/3600 seconds

PFS (Y/N): N

Interface using crypto map set cm10:

GigabitEthernet4/1

Crypto Map “cm100” 1 ipsec

Peer = Auto Peer

IP ACL = acl100

permit ip 10.10.100.0 255.255.255.0 10.10.100.0 255.255.255.0

Transform-sets: 3des-md5, des-md5,

Security Association Lifetime: 4500 megabytes/3600 seconds

PFS (Y/N): N

Interface using crypto map set cm100:

GigabitEthernet4/2

Example 7-9 Displays the Crypto Map Information for a Specific Interface

switch# show crypto map domain ipsec interface gigabitethernet 4/1

Crypto Map “cm10” 1 ipsec

Peer = Auto Peer

IP ACL = acl10

permit ip 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

Transform-sets: 3des-md5, des-md5,

Security Association Lifetime: 4500 megabytes/120 seconds

PFS (Y/N): N

Interface using crypto map set cm10:

GigabitEthernet4/1

Example 7-10 Displays the Specified Crypto Map Information

switch# show crypto map domain ipsec tag cm100

Crypto Map “cm100” 1 ipsec

Peer = Auto Peer

IP ACL = acl100

permit ip 10.10.100.0 255.255.255.0 10.10.100.0 255.255.255.0

Transform-sets: 3des-md5, des-md5,

Security Association Lifetime: 4500 megabytes/120 seconds

PFS (Y/N): N

Interface using crypto map set cm100:

GigabitEthernet4/2

Example 7-11 Displays SA Association for the Specified Interface

switch# show crypto sad domain ipsec interface gigabitethernet 4/1

interface: GigabitEthernet4/1

Crypto map tag: cm10, local addr. 10.10.10.1

protected network:

local ident (addr/mask): (10.10.10.0/255.255.255.0)

remote ident (addr/mask): (10.10.10.4/255.255.255.255)

current_peer: 10.10.10.4

local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.10.4

mode: tunnel, crypto algo: esp-3des, auth algo: esp-md5-hmac

current outbound spi: 0x30e000f (51249167), index: 0

lifetimes in seconds:: 120

lifetimes in bytes:: 423624704

current inbound spi: 0x30e0000 (51249152), index: 0

lifetimes in seconds:: 120

lifetimes in bytes:: 423624704

Example 7-12 Displays All SA Associations

switch# show crypto sad domain ipsec

interface: GigabitEthernet4/1

Crypto map tag: cm10, local addr. 10.10.10.1

protected network:

local ident (addr/mask): (10.10.10.0/255.255.255.0)

remote ident (addr/mask): (10.10.10.4/255.255.255.255)

current_peer: 10.10.10.4

local crypto endpt.: 10.10.10.1, remote crypto endpt.: 10.10.10.4

mode: tunnel, crypto algo: esp-3des, auth algo: esp-md5-hmac

current outbound spi: 0x30e000f (51249167), index: 0

lifetimes in seconds:: 120

lifetimes in bytes:: 423624704

current inbound spi: 0x30e0000 (51249152), index: 0

lifetimes in seconds:: 120

lifetimes in bytes:: 423624704

Example 7-13 Displays Information About the Policy Database

switch# show crypto spd domain ipsec

Policy Database for interface: GigabitEthernet4/1, direction: Both

# 0: deny udp any port eq 500 any

# 1: deny udp any any port eq 500

# 2: permit ip 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

# 63: deny ip any any

Policy Database for interface: GigabitEthernet4/2, direction: Both

# 0: deny udp any port eq 500 any <-----------------------UDP default entry

# 1: deny udp any any port eq 500 <---------------------- UDP default entry

# 3: permit ip 10.10.100.0 255.255.255.0 10.10.100.0 255.255.255.0

# 63: deny ip any any <---------------------------------------- Clear text default entry

Example 7-14 Displays SPD Information for a Specific Interface

switch# show crypto spd domain ipsec interface gigabitethernet 4/2

Policy Database for interface: GigabitEthernet3/1, direction: Both

# 0: deny udp any port eq 500 any

# 1: deny udp any any port eq 500

# 2: permit ip 10.10.10.0 255.255.255.0 10.10.10.0 255.255.255.0

# 127: deny ip any any

Example 7-15 Displays Detailed iSCSI Session Information for a Specific Interface

switch# show iscsi session detail

Initiator iqn.1987-05.com.cisco:01.9f39f09c7468 (ips-host16.cisco.com)

Initiator ip addr (s): 10.10.10.5

Session #1 (index 24)

Discovery session, ISID 00023d000001, Status active

Session #2 (index 25)

Target ibm1

VSAN 1, ISID 00023d000001, TSIH 0, Status active, no reservation

Type Normal, ExpCmdSN 42, MaxCmdSN 57, Barrier 0

MaxBurstSize 0, MaxConn 1, DataPDUInOrder Yes

DataSeqInOrder Yes, InitialR2T Yes, ImmediateData No

Registered LUN 0, Mapped LUN 0

Stats:

PDU: Command: 41, Response: 41

Bytes: TX: 21388, RX: 0

Number of connection: 1

Connection #1

iSCSI session is protected by IPSec <-----------The iSCSI session protection status

Local IP address: 10.10.10.4, Peer IP address: 10.10.10.5

CID 0, State: Full-Feature

StatSN 43, ExpStatSN 0

MaxRecvDSLength 131072, our_MaxRecvDSLength 262144

CSG 3, NSG 3, min_pdu_size 48 (w/ data 48)

AuthMethod none, HeaderDigest None (len 0), DataDigest None (len 0)

Version Min: 0, Max: 0

FC target: Up, Reorder PDU: No, Marker send: No (int 0)

Received MaxRecvDSLen key: Yes

Example 7-16 Displays FCIP Information for a Specific Interface

switch# show interface fcip 1

fcip1 is trunking

Hardware is GigabitEthernet

Port WWN is 20:50:00:0d:ec:08:6c:c0

Peer port WWN is 20:10:00:05:30:00:a7:9e

Admin port mode is auto, trunk mode is on

Port mode is TE

Port vsan is 1

Speed is 1 Gbps

Trunk vsans (admin allowed and active) (1)

Trunk vsans (up) (1)

Trunk vsans (isolated) ()

Trunk vsans (initializing) ()

Using Profile id 1 (interface GigabitEthernet2/1)

Peer Information

Peer Internet address is 10.10.11.1 and port is 3225

FCIP tunnel is protected by IPSec <-----------The FCIP tunnel protection status

Write acceleration mode is off

Tape acceleration mode is off

Tape Accelerator flow control buffer size is 256 KBytes

IP Compression is disabled

Special Frame is disabled

Maximum number of TCP connections is 2

Time Stamp is disabled

QOS control code point is 0

QOS data code point is 0

B-port mode disabled

TCP Connection Information

2 Active TCP connections

Control connection: Local 10.10.11.2:3225, Remote 10.10.11.1:65520

Data connection: Local 10.10.11.2:3225, Remote 10.10.11.1:65522

2 Attempts for active connections, 0 close of connections

TCP Parameters

Path MTU 1400 bytes

Current retransmission timeout is 200 ms

Round trip time: Smoothed 2 ms, Variance: 1

Advertized window: Current: 124 KB, Maximum: 124 KB, Scale: 6

Peer receive window: Current: 123 KB, Maximum: 123 KB, Scale: 6

Congestion window: Current: 53 KB, Slow start threshold: 48 KB

Current Send Buffer Size: 124 KB, Requested Send Buffer Size: 0 KB

CWM Burst Size: 50 KB

5 minutes input rate 128138888 bits/sec, 16017361 bytes/sec, 7937 frames/sec

5 minutes output rate 179275536 bits/sec, 22409442 bytes/sec, 46481 frames/sec

10457037 frames input, 21095415496 bytes

308 Class F frames input, 32920 bytes

10456729 Class 2/3 frames input, 21095382576 bytes

9907495 Reass frames

0 Error frames timestamp error 0

63792101 frames output, 30250403864 bytes

472 Class F frames output, 46816 bytes

63791629 Class 2/3 frames output, 30250357048 bytes

0 Error frames

Example 7-17 Displays the Global IPsec Statistics for the Switch

switch# show crypto global domain ipsec

IPSec global statistics:

Number of crypto map sets: 3

IKE transaction stats: 0 num, 256 max

Inbound SA stats: 0 num

Outbound SA stats: 0 num

Example 7-18 Displays the IPsec Statistics for the Specified Interface

switch# show crypto global domain ipsec interface gigabitethernet 3/1

IPSec interface statistics:

IKE transaction stats: 0 num

Inbound SA stats: 0 num, 512 max

Outbound SA stats: 0 num, 512 max

Example 7-19 Displays the Global SA Lifetime Values

switch# show crypto global domain ipsec security-association lifetime

Security Association Lifetime: 450 gigabytes/3600 seconds

Configuration Examples for IPsec

The following are the configuration examples for IPsec:

- “Sample FCIP Configuration” section

- “Sample iSCSI Configuration” section

Sample FCIP Configuration

Figure 7-11 focuses on implementing IPsec for one FCIP link (Tunnel 2). Tunnel 2 carries encrypted data between MDS A and MDS C.

Figure 7-11 IP Security Usage in an FCIP Scenario

To configure IPsec for the FCIP scenario shown in Figure 7-11, follow these steps:

Step 1 Enable IKE and IPsec in Switch MDS A.

sw10.1.1.100# conf t

sw10.1.1.100(config)# feature crypto ike

sw10.1.1.100(config)# feature crypto ipsec

Step 2 Configure IKE in Switch MDS A.

sw10.1.1.100(config)# crypto ike domain ipsec

sw10.1.1.100(config-ike-ipsec)# key ctct address 10.10.100.232

sw10.1.1.100(config-ike-ipsec)# policy 1

sw10.1.1.100(config-ike-ipsec-policy)# encryption 3des

sw10.1.1.100(config-ike-ipsec-policy)# hash md5

sw10.1.1.100(config-ike-ipsec-policy)# end

sw10.1.1.100#

Step 3 Configure the ACLs in Switch MDS A.

sw10.1.1.100# conf t

sw10.1.1.100(config)# ip access-list acl1 permit tcp 10.10.100.231 0.0.0.0 10.10.100.232 0.0.0.0

Step 4 Configure the transform set in Switch MDS A.

sw10.1.1.100(config)# crypto transform-set domain ipsec tfs-02 esp-aes 128 esp-sha1-hmac

Step 5 Configure the crypto map in Switch MDS A.

sw10.1.1.100(config)# crypto map domain ipsec cmap-01 1

sw10.1.1.100(config-crypto-map-ip)# match address acl1

sw10.1.1.100(config-crypto-map-ip)# set peer 10.10.100.232

sw10.1.1.100(config-crypto-map-ip)# set transform-set tfs-02

sw10.1.1.100(config-crypto-map-ip)# set security-association lifetime seconds 120

sw10.1.1.100(config-crypto-map-ip)# set security-association lifetime gigabytes 3000

sw10.1.1.100(config-crypto-map-ip)# set pfs group5

sw10.1.1.100(config-crypto-map-ip)# end

sw10.1.1.100#

Step 6 Bind the interface to the crypto map set in Switch MDS A.

sw10.1.1.100# conf t

sw10.1.1.100(config)# int gigabitethernet 7/1

sw10.1.1.100(config-if)# ip addr 10.10.100.231 255.255.255.0

sw10.1.1.100(config-if)# crypto map domain ipsec cmap-01

sw10.1.1.100(config-if)# no shut

sw10.1.1.100(config-if)# exit

sw10.1.1.100(config)#

Step 7 Configure FCIP in Switch MDS A.

sw10.1.1.100(config)# feature fcip

sw10.1.1.100(config)# fcip profile 2

sw10.1.1.100(config-profile)# ip address 10.10.100.231

sw10.1.1.100(config-profile)# int fcip 2

sw10.1.1.100(config-if)# peer-info ipaddr 10.10.100.232

sw10.1.1.100(config-if)# use-profile 2

sw10.1.1.100(config-if)# no shut

sw10.1.1.100(config-if)# end

sw10.1.1.100#

Step 8 Verify the configuration in Switch MDS A.

sw10.1.1.100# show crypto global domain ipsec security-association lifetime

Security Association Lifetime: 4500 megabytes/3600 seconds

sw10.1.1.100# show crypto map domain ipsec

Crypto Map “cmap-01” 1 ipsec

Peer = 10.10.100.232

IP ACL = acl1

permit ip 10.10.100.231 255.255.255.255 10.10.100.232 255.255.255.255

Transform-sets: tfs-02,

Security Association Lifetime: 3000 gigabytes/120 seconds

PFS (Y/N): Y

PFS Group: group5

Interface using crypto map set cmap-01:

GigabitEthernet7/1

sw10.1.1.100# show crypto transform-set domain ipsec

Transform set: tfs-02 {esp-aes 128 esp-sha1-hmac}

will negotiate {tunnel}

sw10.1.1.100# show crypto spd domain ipsec

Policy Database for interface: GigabitEthernet7/1, direction: Both

# 0: deny udp any port eq 500 any

# 1: deny udp any any port eq 500

# 2: permit ip 10.10.100.231 255.255.255.255 10.10.100.232 255.255.255.255

# 63: deny ip any any

sw10.1.1.100# show crypto ike domain ipsec

keepalive 3600

sw10.1.1.100# show crypto ike domain ipsec key

key ctct address 10.10.100.232

sw10.1.1.100# show crypto ike domain ipsec policy

Priority 1, auth pre-shared, lifetime 86300 secs, encryption 3des, hash md5, DH group 1

Step 9 Enable IKE and IPsec in Switch MDS C.

sw11.1.1.100# conf t

sw11.1.1.100(config)# feature crypto ike

sw11.1.1.100(config)# feature crypto ipsec

Step 10 Configure IKE in Switch MDS C.

sw11.1.1.100(config)# crypto ike domain ipsec

sw11.1.1.100(config-ike-ipsec)# key ctct address 10.10.100.231

sw11.1.1.100(config-ike-ipsec)# policy 1

sw11.1.1.100(config-ike-ipsec-policy)# encryption 3des

sw11.1.1.100(config-ike-ipsec-policy)# hash md5

sw11.1.1.100(config-ike-ipsec-policy)# exit

sw11.1.1.100(config-ike-ipsec)# end

sw11.1.1.100#

Step 11 Configure the ACLs in Switch MDS C.

sw11.1.1.100# conf t

sw11.1.1.100(config)# ip access-list acl1 permit ip 10.10.100.232 0.0.0.0 10.10.100.231 0.0.0.0

Step 12 Configure the transform set in Switch MDS C.

sw11.1.1.100(config)# crypto transform-set domain ipsec tfs-02 esp-aes 128 esp-sha1-hmac

Step 13 Configure the crypto map in Switch MDS C.

sw11.1.1.100(config)# crypto map domain ipsec cmap-01 1

sw11.1.1.100(config-crypto-map-ip)# match address acl1

sw11.1.1.100(config-crypto-map-ip)# set peer 10.10.100.231

sw11.1.1.100(config-crypto-map-ip)# set transform-set tfs-02

sw11.1.1.100(config-crypto-map-ip)# set security-association lifetime seconds 120

sw11.1.1.100(config-crypto-map-ip)# set security-association lifetime gigabytes 3000

sw11.1.1.100(config-crypto-map-ip)# set pfs group5

sw11.1.1.100(config-crypto-map-ip)# exit

sw11.1.1.100(config)#

Step 14 Bind the interface to the crypto map set in Switch MDS C.

sw11.1.1.100(config)# int gigabitethernet 1/2

sw11.1.1.100(config-if)# ip addr 10.10.100.232 255.255.255.0

sw11.1.1.100(config-if)# crypto map domain ipsec cmap-01

sw11.1.1.100(config-if)# no shut

sw11.1.1.100(config-if)# exit

sw11.1.1.100(config)#

Step 15 Configure FCIP in Switch MDS C.

sw11.1.1.100(config)# feature fcip

sw11.1.1.100(config)# fcip profile 2

sw11.1.1.100(config-profile)# ip address 10.10.100.232

sw11.1.1.100(config-profile)# int fcip 2

sw11.1.1.100(config-if)# peer-info ipaddr 10.10.100.231

sw11.1.1.100(config-if)# use-profile 2

sw11.1.1.100(config-if)# no shut

sw11.1.1.100(config-if)# exit

sw11.1.1.100(config)# exit

Step 16 Verify the configuration in Switch MDS C.

sw11.1.1.100# show crypto global domain ipsec security-association lifetime

Security Association Lifetime: 4500 megabytes/3600 seconds

sw11.1.1.100# show crypto map domain ipsec

Crypto Map “cmap-01” 1 ipsec

Peer = 10.10.100.231

IP ACL = acl1

permit ip 10.10.100.232 255.255.255.255 10.10.100.231 255.255.255.255

Transform-sets: tfs-02,

Security Association Lifetime: 3000 gigabytes/120 seconds

PFS (Y/N): Y

PFS Group: group5

Interface using crypto map set cmap-01:

GigabitEthernet1/2

sw11.1.1.100# show crypto spd domain ipsec

Policy Database for interface: GigabitEthernet1/2, direction: Both

# 0: deny udp any port eq 500 any

# 1: deny udp any any port eq 500

# 2: permit ip 10.10.100.232 255.255.255.255 10.10.100.231 255.255.255.255

# 63: deny ip any any

sw11.1.1.100# show crypto sad domain ipsec

interface: GigabitEthernet1/2

Crypto map tag: cmap-01, local addr. 10.10.100.232

protected network:

local ident (addr/mask): (10.10.100.232/255.255.255.255)

remote ident (addr/mask): (10.10.100.231/255.255.255.255)

current_peer: 10.10.100.231

local crypto endpt.: 10.10.100.232, remote crypto endpt.: 10.10.100.231

mode: tunnel, crypto algo: esp-3des, auth algo: esp-md5-hmac

current outbound spi: 0x38f96001 (955867137), index: 29

lifetimes in seconds:: 120

lifetimes in bytes:: 3221225472000

current inbound spi: 0x900b011 (151040017), index: 16

lifetimes in seconds:: 120

lifetimes in bytes:: 3221225472000

sw11.1.1.100# show crypto transform-set domain ipsec

Transform set: tfs-02 {esp-aes 128 esp-sha1-hmac}

will negotiate {tunnel}

sw11.1.1.100# show crypto ike domain ipsec

keepalive 3600

sw11.1.1.100# show crypto ike domain ipsec key

key ctct address 10.10.100.231

sw11.1.1.100# show crypto ike domain ipsec policy

Priority 1, auth pre-shared, lifetime 86300 secs, encryption 3des, hash md5, DH

group 1

sw11.1.1.100# show crypto ike domain ipsec sa

Tunn Local Addr Remote Addr Encr Hash Auth Method Lifetime

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

1* 10.10.100.232[500] 10.10.100.231[500] 3des md5 preshared key 86300

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

NOTE: tunnel id ended with * indicates an IKEv1 tunnel

Step 17 Verify the configuration in Switch MDS A.

sw10.1.1.100# show crypto sad domain ipsec

interface: GigabitEthernet7/1

Crypto map tag: cmap-01, local addr. 10.10.100.231

protected network:

local ident (addr/mask): (10.10.100.231/255.255.255.255)

remote ident (addr/mask): (10.10.100.232/255.255.255.255)

current_peer: 10.10.100.232

local crypto endpt.: 10.10.100.231, remote crypto endpt.: 10.10.100.232

mode: tunnel, crypto algo: esp-3des, auth algo: esp-md5-hmac

current outbound spi: 0x900b01e (151040030), index: 10

lifetimes in seconds:: 120

lifetimes in bytes:: 3221225472000

current inbound spi: 0x38fe700e (956198926), index: 13

lifetimes in seconds:: 120

lifetimes in bytes:: 3221225472000

sw10.1.1.100# show crypto ike domain ipsec sa

Tunn Local Addr Remote Addr Encr Hash Auth Method Lifetime

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

1 10.10.100.231[500] 10.10.100.232[500] 3des md5 preshared key 86300

You have now configured IPsec in both switches MDS A and MDS C.

Sample iSCSI Configuration

option, when any host from the subnet 12.12.1.0/24 tries to connect to the MDS switch’s Gigabit Ethernet port 7/1, an SA is created between the hosts and the MDS switch. With auto-peer, only one crypto map is necessary to create SAs for all the hosts in the same subnet. Without auto-peer, you need one crypto map entry per host.

Figure 7-12 iSCSI with End-to-End IPsec

To configure IPsec for the iSCSI scenario shown in Figure 7-12, follow these steps:

Step 1 Configure the ACLs in Switch MDS A.

sw10.1.1.100# conf t

sw10.1.1.100(config)# ip access-list acl1 permit tcp 10.10.1.0 0.0.0.255 range port 3260 3260 12.12.1.0 0.0.0.255

Step 2 Configure the transform set in Switch MDS A.

sw10.1.1.100(config)# crypto transform-set domain ipsec tfs-01 esp-3des esp-md5-hmac

Step 3 Configure the crypto map in Switch MDS A.

sw10.1.1.100(config)# crypto map domain ipsec cmap-01 1

sw10.1.1.100(config-crypto-map-ip)# match address acl1

sw10.1.1.100(config-crypto-map-ip)# set peer auto-peer

sw10.1.1.100(config-crypto-map-ip)# set transform-set tfs-01

sw10.1.1.100(config-crypto-map-ip)# end

sw10.1.1.100#

Step 4 Bind the interface to the crypto map set in Switch MDS A.

sw10.1.1.100# conf t

sw10.1.1.100(config)# int gigabitethernet 7/1

sw10.1.1.100(config-if)# ip address 10.10.1.123 255.255.255.0

sw10.1.1.100(config-if)# crypto map domain ipsec cmap-01

sw10.1.1.100(config-if)# no shut

sw10.1.1.100(config-if)# end

sw10.1.1.100#

You have now configured IPsec in MDS A using the Cisco MDS IPsec and iSCSI features.

Field Descriptions for IPsec

The following are the field descriptions for IPsec.

IPsec

Field

Description

Interface, CryptomapName

The binding of cryptomap sets to the interfaces of the managed entity.

IKE Global

Field

Description

RemIdentity

Displays the keepalive interval in seconds used by the IKE entity on the managed device with all the peers for the DOI corresponding to this conceptual row.

Key

Displays the type of keepalives to be used by the IKE entity on the managed device with all the peers for the DOI corresponding to this conceptual row.

IKE Pre-Shared AuthKey

Field

Description

KeepAliveInterval (sec)

The Phase 1 ID identity of the peer for which this pre-shared key is configured on the local entity.

IdentityType

The pre-shared authorization key used in authenticating the peer corresponding to this conceptual row.

IKE Policies

Field

Description

Priority

The priority of this ISAKMP policy entry. The policy with lower value would take precedence over the policy with higher value in the same DOI.

Encr

The encryption transform specified by this ISAKMP policy specification. The Internet Key Exchange (IKE) tunnels setup using this policy item would use the specified encryption transform to protect the ISAKMP PDUs.

Hash

The hash transform specified by this ISAKMP policy specification. The IKE tunnels setup using this policy item would use the specified hash transform to protect the ISAKMP PDUs.

Auth

The peer authentication method specified by this ISAKMP policy specification. If this policy entity is selected for negotiation with a peer, the local entity would authenticate the peer using the method specified by this object.

DHGroup

Specifies the Oakley group used for Diffie Hellman exchange in the Main Mode. If this policy item is selected to negotiate Main Mode with an IKE peer, the local entity chooses the group specified by this object to perform Diffie Hellman exchange with the peer.

Lifetime (sec)

Specifies the lifetime in seconds of the IKE tunnels generated using this policy specification.

IKE Initiator Version

Field

Description

Address

The address of the remote peer corresponding to this conceptual row. This object cannot be modified while the corresponding value of cicIkeCfgInitiatorStatus is equal to active.

Version

The IKE protocol version used when connecting to a remote peer specified in cicIkeCfgInitiatorPAddr. This object cannot be modified while the corresponding value of cicIkeCfgInitiatorStatus is equal to active.

IKE Tunnels

Field

Description

LocalAddress

The address of the local endpoint for the Phase-1 tunnel.

RemoteAddresss

The address of the remote endpoint of the Phase-1 tunnel.

AuthMethod

The authentication method used in Phase-1 negotiations on the control tunnel corresponding to this conceptual row.

Action

The action to be taken on this tunnel. If clear, then this tunnel is cleared. If re-key, then re-keying is forced on this tunnel. The value none would be returned on doing read of this object.

IPSEC Global

Field

Description

Lifetime (sec)

The default lifetime (in seconds) assigned to an IPsec tunnel as a global policy (maybe overridden in specific cryptomap definitions).

Lifesize (KB)

The default life size in KB assigned to an IPsec tunnel as a global policy (unless overridden in cryptomap definition).

IPSEC Transform Set

Field

Description

Id

This is the sequence number of the transform set that uniquely identifies the transform set. Distinct transform sets must have distinct sequence numbers.

Protocol

Represents the suite of Phase-2 security protocols of this transform set.

ESP Encryption

Represents the transform used for ESP encryption.

ESP Authentication

Represents the transform used to implement integrity check with ESP protocol.

Mode

Represents the encapsulation mode of the transform set.

IPSEC CryptoMap Set Entry

Field

Description

IpFilter

Specifies an IP protocol filter to be secured using this cryptomap entry. When it has a value of zero-length string, it is not valid/applicable.

TransformSetIdList

The list of cipsXformSetId that are members of this CipsStaticCryptomapEntry. The value of this object is a concatenation of zero ormore 4-octet strings, where each 4-octet string contains a 32-bit cipsXformSetId value in network byte order. A zero length string value means this list has no members.

AutoPeer

If true the destination address is taken as the peer address, while creating the tunnel.

Peer Address

The IP address of the peer to which this cryptomap entry is currently connected.

PFS

Identifies whether the tunnels instantiated due to this policy item should use Perfect Forward Secrecy (PFS) and if so, what group of Oakley they should use.

LifeTime

Specifies the lifetime of the IPsec Security Associations (SA) created using this IPsec policy entry.

Lifesize Value

Identifies the life size (maximum traffic in bytes that may be carried) of the IPSec SAs created using this IPSec policy entry. When a Security Association (SA) is created using this IPsec policy entry, its life size takes the value of this object.

IPSEC Interfaces

Field

Description

CryptomapName

The index of the static cryptomap table. The value of the string is the name string assigned by the NMS when defining a cryptomap set.

InterfaceList

Interfaces belong to the cryptomap.

IPSEC Tunnels

Field

Description

Local Address

The IP address of the local endpoint for the IPsec Phase-2 tunnel.

RemoteAdddress

The type of the IP address of the remote endpoint for the IPsec Phase-2 tunnel.

ESP Encryption

The encryption algorithm used by the outbound security association of the IPsec Phase-2 tunnel.

ESP Encryption KeySize

The key size in bits of the negotiated key to be used with the algorithm denoted by ceipSecTunOutSaEncryptAlgo. For DES and 3DES the key size is respectively 56 and 168. For AES, this will denote the negotiated key size.

ESP Authentication

The authentication algorithm used by the inbound encapsulation security protocol (ESP) security association of the IPsec Phase-2 tunnel.

LifeSize (KB)

The negotiated life size of the IPSEC Phase-2 tunnel in kilobytes.

LifeTime (sec)

The negotiated lifetime of the IPSEC Phase-2 tunnel in seconds. If the tunnel was setup manually, the value of this MIB element should be 0.

Action

The status of the MIB table row.

Configuring FC-SP and DHCHAP

This chapter includes the following topics:

- Information About Fabric Authentication

- Default Settings

- Configuring DHCAP

- Verifying FC-SP and DHCHAP Configuration

- Configuration Example for DHCHAP

Information About Fabric Authentication

Fibre Channel Security Protocol (FC-SP) capabilities provide switch-switch and host-switch authentication to overcome security challenges for enterprise-wide fabrics. Diffie-Hellman Challenge Handshake Authentication Protocol (DHCHAP) is an FC-SP protocol that provides authentication between Cisco MDS 9000 Family switches and other devices. DHCHAP consists of the CHAP protocol combined with the Diffie-Hellman exchange.

To authenticate through VFC ports, FC-SP peers use the port VSAN for communication. Hence, the port VSAN needs to be the same and active on both the peers to send and receive authentication messages.

All switches in the Cisco MDS 9000 Family enable fabric-wide authentication from one switch to another switch, or from a switch to a host. These switch and host authentications are performed locally or remotely in each fabric. As storage islands are consolidated and migrated to enterprise-wide fabrics new security challenges arise. The approach of securing storage islands cannot always be guaranteed in enterprise-wide fabrics.

For example, in a campus environment with geographically distributed switches someone could maliciously interconnect incompatible switches or you could accidentally do so, resulting in Inter-Switch Link (ISL) isolation and link disruption. This need for physical security is addressed by switches in the Cisco MDS 9000 Family (see Figure 8-1).

Figure 8-1 Switch and Host Authentication

Note Fibre Channel (FC) host bus adapters (HBAs) with appropriate firmware and drivers are required for host-switch authentication.

DHCHAP

DHCHAP is an authentication protocol that authenticates the devices connecting to a switch. Fibre Channel authentication allows only trusted devices to be added to a fabric, which prevents unauthorized devices from accessing the switch.

Note The terms FC-SP and DHCHAP are used interchangeably in this chapter.

DHCHAP is a mandatory password-based, key-exchange authentication protocol that supports both switch-to-switch and host-to-switch authentication. DHCHAP negotiates hash algorithms and DH groups before performing authentication. It supports MD5 and SHA-1 algorithm-based authentication.

Configuring the DHCHAP feature requires the ENTERPRISE_PKG license (see the Cisco MDS 9000 Family NX-OS Licensing Guide).

DHCHAP Compatibility with Existing Cisco MDS Features

This section identifies the impact of configuring the DHCHAP feature along with existing Cisco MDS features:

- PortChannel interfaces—If DHCHAP is enabled for ports belonging to a PortChannel, DHCHAP authentication is performed at the physical interface level, not at the PortChannel level.

- FCIP interfaces—The DHCHAP protocol works with the FCIP interface just as it would with a physical interface.

- Port security or fabric binding—Fabric binding policies are enforced based on identities authenticated by DHCHAP.

- VSANs—DHCHAP authentication is not done on a per-VSAN basis.

- High availability—DHCHAP authentication works transparently with existing HA features.

About Enabling DHCHAP

By default, the DHCHAP feature is disabled in all switches in the Cisco MDS 9000 Family.

You must explicitly enable the DHCHAP feature to access the configuration and verification commands for fabric authentication. When you disable this feature, all related configurations are automatically discarded.

About DHCHAP Authentication Modes

The DHCHAP authentication status for each interface depends on the configured DHCHAP port mode.

When the DHCHAP feature is enabled in a switch, each Fibre Channel interface or FCIP interface may be configured to be in one of four DHCHAP port modes:

- On—During switch initialization, if the connecting device supports DHCHAP authentication, the software performs the authentication sequence. If the connecting device does not support DHCHAP authentication, the software moves the link to an isolated state.

- Auto-Active—During switch initialization, if the connecting device supports DHCHAP authentication, the software performs the authentication sequence. If the connecting device does not support DHCHAP authentication, the software continues with the rest of the initialization sequence.

- Auto-Passive (default)—The switch does not initiate DHCHAP authentication, but participates in DHCHAP authentication if the connecting device initiates DHCHAP authentication.

- Off—The switch does not support DHCHAP authentication. Authentication messages sent to such ports return error messages to the initiating switch.

Note Whenever DHCHAP port mode is changed to a mode other than the Off mode, reauthentication is performed.

identifies the switch-to-switch authentication behavior between two Cisco MDS switches in various modes.

Table 8-1 DHCHAP Authentication Status Between Two MDS Switches

Switch N

DHCHAP Modes

Switch 1 DHCHAP Modes

on

auto-active

auto-passive

off

on

FC-SP authentication is performed.

FC-SP authentication is performed.

FC-SP authentication is performed.

Link is brought down.

auto-Active

performed.

auto-Passive

performed.

off

Link is brought down.

performed.

About the DHCHAP Hash Algorithm

Cisco MDS switches support a default hash algorithm priority list of MD5 followed by SHA-1 for DHCHAP authentication.

Tip If you change the hash algorithm configuration, then change it globally for all switches in the fabric.

Caution RADIUS and TACACS+ protocols always use MD5 for CHAP authentication. Using SHA-1 as the hash algorithm may prevent RADIUS and TACACS+ usage—even if these AAA protocols are enabled for DHCHAP authentication.

About the DHCHAP Group Settings

All switches in the Cisco MDS Family support all DHCHAP groups specified in the standard: 0 (null DH group, which does not perform the Diffie-Hellman exchange), 1, 2, 3, or 4.

Tip If you change the DH group configuration, change it globally for all switches in the fabric.

About the DHCHAP Password

DHCHAP authentication in each direction requires a shared secret password between the connected devices. To do this, you can use one of three approaches to manage passwords for all switches in the fabric that participate in DHCHAP.

- Approach 1—Use the same password for all switches in the fabric. This is the simplest approach. When you add a new switch, you use the same password to authenticate that switch in this fabric. It is also the most vulnerable approach if someone from the outside maliciously attempts to access any one switch in the fabric.

- Approach 2—Use a different password for each switch and maintain that password list in each switch in the fabric. When you add a new switch, you create a new password list and update all switches with the new list. Accessing one switch yields the password list for all switches in that fabric.

- Approach 3—Use different passwords for different switches in the fabric. When you add a new switch, multiple new passwords corresponding to each switch in the fabric must be generated and configured in each switch. Even if one switch is compromised, the password of other switches are still protected. This approach requires considerable password maintenance by the user.

Note All passwords are restricted to 64 alphanumeric characters and can be changed, but not deleted.

Tip We recommend using RADIUS or TACACS+ for fabrics with more than five switches. If you need to use a local password database, you can continue to do so using Approach 3 and using the Cisco MDS 9000 Family DCNM-SAN to manage the password database.

About Password Configuration for Remote Devices

You can configure passwords in the local authentication database for other devices in a fabric. The other devices are identified by their device name, which is also known as the switch WWN or device WWN. The password is restricted to 64 characters and can be specified in clear text (0) or in encrypted text (7).

Note The switch WWN identifies the physical switch. This WWN is used to authenticate the switch and is different from the VSAN node WWN.

About the DHCHAP Timeout Value

During the DHCHAP protocol exchange, if the MDS switch does not receive the expected DHCHAP message within a specified time interval, authentication failure is assumed. The time ranges from 20 (no authentication is performed) to 1000 seconds. The default is 30 seconds.

When changing the timeout value, consider the following factors:

- The existing RADIUS and TACACS+ timeout values.

The same value must also be configured on all switches in the fabric.

Enabling FC-SP on ISLs

There is an ISL pop-up menu in DCNM-SAN called Enable FC-SP that enables FC-SP on switches at either end of the ISL. You are prompted for an FC-SP generic password, then asked to set FC-SP interface mode to ON for affected ports. Right-click an ISL and click Enable FC-SP to access this feature.

Note FC-SP DHCHAP mode requires port-flap on both end of the ISL.

Default Settings

lists the default settings for all fabric security features in any switch.

Table 8-2 Default Fabric Security Settings

Parameters

Default

DHCHAP feature

Disabled

DHCHAP hash algorithm

A priority list of MD5 followed by SHA-1 for DHCHAP authentication

DHCHAP authentication mode

Auto-passive

DHCHAP group default priority exchange order

0, 4, 1, 2, and 3 respectively

DHCHAP timeout value

30 seconds

Configuring DHCAP

To configure DHCHAP authentication using the local password database, follow these steps:

Step 1 Enable DHCHAP.

Step 2 Identify and configure the DHCHAP authentication modes.

Step 3 Configure the hash algorithm and DH group.

Step 4 Configure the DHCHAP password for the local switch and other switches in the fabric.

Step 5 Configure the DHCHAP timeout value for reauthentication.

Step 6 Verify the DHCHAP configuration.

Enabling DHCHAP

To enable DHCHAP for a Cisco MDS switch, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables the DHCHAP in this switch.

Disables (default) the DHCHAP in this switch.

To enable DHCHAP for a Cisco MDS switch , follow these steps:

Step 1 Expand Switches, expand Security and then select FC-SP.

The Control tab is the default. You see the FC-SP enable state for all switches in the fabric.

Step 2 Set the Command drop-down menu to enable for all switches that you want to enable FC-SP on.

Step 3 Click the Apply Changes icon to enable FC-SP and DHCHAP on the selected switches.

Configuring the DHCHAP Mode

To configure the DHCHAP mode for a particular interface, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config-if)#

Selects a range of interfaces and enters the interface configuration submode.

Step 3

Sets the DHCHAP mode for the selected interfaces to be in the on state.

Reverts to the factory default of auto-passive for these three interfaces.

Step 4

Changes the DHCHAP authentication mode for the selected interfaces to auto-active. Zero (0) indicates that the port does not perform reauthentication.

Note The reauthorization interval configuration is the same as the default behavior.

Changes the DHCHAP authentication mode to auto-active for the selected interfaces and enables reauthentication every two hours (120 minutes) after the initial authentication.

Changes the DHCHAP authentication mode to auto-active for the selected interfaces. Reauthentication is disabled (default).

Note The reauthorization interval configuration is the same as setting it to zero (0).

To configure the DHCHAP mode for a particular interface, follow these steps:

Step 1 Expand Switches, expand Interfaces, and then select FC Physical.

You see the interface configuration in the Information pane.

Step 2 Click the FC-SP tab.

drop-down menu to the DHCHAP authentication mode you want to configure for that interface.

Step 4 Click the Apply Changes icon to save these DHCHAP port mode settings.

Configuring the DHCHAP Hash Algorithm

To configure the hash algorithm, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the use of only the SHA-1 hash algorithm.

Configures the use of only the MD5 hash algorithm.

Defines the use of the default hash algorithm priority list of MD5 followed by SHA-1 for DHCHAP authentication.

Reverts to the factory default priority list of the MD5 hash algorithm followed by the SHA-1 hash algorithm.

To configure the hash algorithm, follow these steps:

Step 1 Choose Switches > Security, and then select FC-SP.

Step 2 Click the General/Password tab.

You see the DHCHAP general settings mode for each switch.

Step 3 Change the DHCHAP HashList for each switch in the fabric.

Step 4 Click the Apply Changes icon to save the updated hash algorithm priority list.

Configuring the DHCHAP Group Settings

To change the DH group settings, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Prioritizes the use of DH group 2, 3, and 4 in the configured order.

Reverts to the DHCHAP factory default order of 0, 4, 1, 2, and 3.

To change the DH group settings, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP.

Step 2 Click the General/Password tab.

Step 3 Change the DHCHAP GroupList for each switch in the fabric.

Step 4 Click the Apply Changes icon to save the updated hash algorithm priority list.

Configuring DHCHAP Passwords for the Local Switch

To configure the DHCHAP password for the local switch, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures a clear text password for the local switch.

Configures a clear text password for the local switch to be used for the device with the specified WWN.

Removes the clear text password for the local switch to be used for the device with the specified WWN.

Configures a password entered in an encrypted format for the local switch.

Configures a password entered in an encrypted format for the local switch to be used for the device with the specified WWN.

Removes the password entered in an encrypted format for the local switch to be used for the device with the specified WWN.

Configures a clear text password for the local switch to be used with any connecting device.

To configure the DHCHAP password for the local switch, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP.

You see the FC-SP configuration in the Information pane.

Step 2 Click the Local Passwords tab.

icon to create a new local password.

You see the Create Local Passwords dialog box.

Step 4 (Optional) Check the switches that you want to configure the same local password on.

Step 5 Select the switch WNN and fill in the Password field.

Step 6 Click Create to save the updated password.

Configuring DHCHAP Passwords for Remote Devices

To locally configure the remote DHCHAP password for another switch in the fabric, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures a password for another switch in the fabric that is identified by the switch WWN device name.

Removes the password entry for this switch from the local authentication database.

Configures a clear text password for another switch in the fabric that is identified by the switch WWN device name.

Configures a password entered in an encrypted format for another switch in the fabric that is identified by the switch WWN device name.

To locally configure the remote DHCHAP password for another switch in the fabric, follow these steps:

Step 1 Right-click an ISL and select Enable FC-SP from the drop-down list (see Figure 8-2).

Figure 8-2 Enable FC-SP

You see the Enable FC-SP dialog box.

Figure 8-3 Enable FC-SP Dialog Box

Step 2 Click Apply to save the updated password.

Configuring the DHCHAP Timeout Value

To configure the DHCHAP timeout value, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Configures the reauthentication timeout to be 60 seconds.

Reverts to the factory default of 30 seconds.

To configure the DHCHAP timeout value, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP.

You see the FC-SP configuration in the Information pane.

Step 2 Click the General/Password tab.

You see the DHCHAP general settings mode for each switch.

Step 3 Change the DHCHAP timeout value for each switch in the fabric.

Step 4 Click the Apply Changes icon to save the updated information.

Configuring DHCHAP AAA Authentication

You can individually set authentication options. If authentication is not configured, local authentication is used by default.

To configure the AAA authentication refer to the Information About Switch Management Security Follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables DHCHAP to use the TACACS+ server group (in this example, TacacsServer1) for authentication.

Enables DHCHAP for local authentication.

Enables DHCHAP to use the RADIUS server group (in this example, RadiusServer1) for authentication.

Verifying FC-SP and DHCHAP Configuration

To display FC-SP and DHCHAP configuration information, perform one of the following tasks:

Command

Purpose

Displays DHCHAP Configurations in FC Interfaces.

Displays DHCHAP Statistics for an FC Interface.

show fcsp interface fc 2/1 wwn

Displays the FC-SP WWN of the Device Connected through a Specified Interface.

show fcsp dhchap

Displays Hash Algorithm and DHCHAP Groups Configured for the Local Switch.

show fcsp dhchap database

Displays the DHCHAP Local Password Database.

show fcsp asciiwwn 30:11:bb:cc:dd:33:11:22

Displays the ASCII Representation of the Device WWN.

.

This section includes the following topics:

- Displaying Protocol Security Information

Displaying Protocol Security Information

).

Example 8-1 Displays DHCHAP Configurations in FC Interfaces

switch# show fcsp interface fc1/9

fc1/9:

fcsp authentication mode:SEC_MODE_ON

Status: Successfully authenticated

Example 8-2 Displays DHCHAP Statistics for an FC Interface

switch# show fcsp interface fc1/9 statistics

fc1/9:

fcsp authentication mode:SEC_MODE_ON

Status: Successfully authenticated

Statistics:

FC-SP Authentication Succeeded:5

FC-SP Authentication Failed:0

FC-SP Authentication Bypassed:0

Example 8-3 Displays the FC-SP WWN of the Device Connected through a Specified Interface

switch# show fcsp interface fc 2/1 wwn

fc2/1:

fcsp authentication mode:SEC_MODE_ON

Status: Successfully authenticated

Other device's WWN:20:00:00:e0:8b:0a:5d:e7

Example 8-4 Displays Hash Algorithm and DHCHAP Groups Configured for the Local Switch

switch# show fcsp dhchap

Supported Hash algorithms (in order of preference):

DHCHAP_HASH_MD5

DHCHAP_HASH_SHA_1

Supported Diffie Hellman group ids (in order of preference):

DHCHAP_GROUP_NULL

DHCHAP_GROUP_1536

DHCHAP_GROUP_1024

DHCHAP_GROUP_1280

DHCHAP_GROUP_2048

Example 8-5 Displays the DHCHAP Local Password Database

switch# show fcsp dhchap database

DHCHAP Local Password:

Non-device specific password:**********

Password for device with WWN:29:11:bb:cc:dd:33:11:22 is ******

Password for device with WWN:30:11:bb:cc:dd:33:11:22 is *********

Other Devices' Passwords:

Password for device with WWN:00:11:22:33:44:aa:bb:cc is ***********

Example 8-6 Displays the ASCII Representation of the Device WWN

switch# show fcsp asciiwwn 30:11:bb:cc:dd:33:11:22

Ascii representation of WWN to be used with AAA servers:Ox_3011bbccdd331122

Tip Use the ASCII representation of the device WWN (identified in bold in Example 8-6) to configure the switch information on RADIUS and TACACS+ servers.

Configuration Example for DHCHAP

This section provides the steps to configure the example illustrated in Figure 8-4.

Figure 8-4 Sample DHCHAP Authentication

To configure the authentication setup shown in Figure 8-4, follow these steps:

Step 1 Obtain the device name of the MDS 9216 Switch in the fabric. The MDS 9216 Switch in the fabric is identified by the switch WWN.

MDS-9216# show wwn switch

Switch WWN is 20:00:00:05:30:00:54:de

Step 2 Explicitly enable DHCHAP in this switch.

Note When you disable DHCHAP, all related configurations are automatically discarded.

MDS-9216(config)# feature fcsp

Step 3 Configure a clear text password for this switch. This password will be used by the connecting device.

MDS-9216(config)# fcsp dhchap password rtp9216

Step 4 Configures a password for another switch in the fabric that is identified by the switch WWN device name.

MDS-9216(config)# fcsp dhchap devicename 20:00:00:05:30:00:38:5e password rtp9509

Step 5 Enable the DHCHAP mode for the required Fibre Channel interface.

Note Whenever DHCHAP port mode is changed to a mode other than the Off mode, reauthentication is performed.

MDS-9216(config)# interface fc 1/16

MDS-9216(config-if)# fcsp on

Step 6 Verify the protocol security information configured in this switch by displaying the DHCHAP local password database.

MDS-9216# show fcsp dhchap database

DHCHAP Local Password:

Non-device specific password:*******

Other Devices' Passwords:

Password for device with WWN:20:00:00:05:30:00:38:5e is *******

Step 7 Display the DHCHAP configuration in the Fibre Channel interface.

MDS-9216# show fcsp interface fc 1/6

fc1/6

fcsp authentication mode:SEC_MODE_ON

Status:Successfully authenticated

Step 8 Repeat these steps on the connecting MDS 9509 Switch.

MDS-9509# show wwn switch

Switch WWN is 20:00:00:05:30:00:38:5e

MDS-9509(config)# feature fcsp

MDS-9509(config)# fcsp dhchap password rtp9509

MDS-9509(config)# fcsp dhchap devicename 20:00:00:05:30:00:54:de password rtp9216

MDS-9509(config)# interface fc 4/5

MDS-9509(config-if)# fcsp on

MDS-9509# show fcsp dhchap database

DHCHAP Local Password:

Non-device specific password:*******

Other Devices' Passwords:

Password for device with WWN:20:00:00:05:30:00:54:de is *******

MDS-9509# show fcsp interface fc 4/5

Fc4/5

fcsp authentication mode:SEC_MODE_ON

Status:Successfully authenticated

Configuring Port Security

All switches in the Cisco MDS 9000 Family provide port security features that reject intrusion attempts and report these intrusions to the administrator.

This chapter includes the following topics:

- Information About Port Security

- Guidelines and Limitations

- Default Settings

- Configuring Port Security

- Configuring Auto-learning

- Configuring Port Security Manually

- Configuring Port Security Distribution

- Interacting with the Database

- Verifying Port Security Configuration

- Field Descriptions for Port Security

- Feature History for Port Security

Information About Port Security

All switches in the Cisco MDS 9000 Family provide port security features that reject intrusion attempts and report these intrusions to the administrator.

Typically, any Fibre Channel device in a SAN can attach to any SAN switch port and access SAN services based on zone membership. Port security features prevent unauthorized access to a switch port in the Cisco MDS 9000 Family in the following ways:

- Login requests from unauthorized Fibre Channel devices (Nx ports) and switches (xE ports) are rejected.

- All intrusion attempts are reported to the SAN administrator through system messages.

- Configuration distribution uses the CFS infrastructure, and is limited to those switches that are CFS capable. Distribution is disabled by default.

- Configuring the port security policy requires the ENTERPRISE_PKG license (see the Cisco MDS 9000 Family NX-OS Licensing Guide).

This section includes the following topics:

- Port Security Enforcement

- About Auto-Learning

- Port Security Activation

- Database Activation Rejection

- About Enabling Auto-learning

- Auto-learning Device Authorization

- Authorization Scenarios

- About WWN Identification

- Activation and Auto-learning Configuration Distribution

- Database Interaction

- Database Scenarios

Port Security Enforcement

To enforce port security, configure the devices and switch port interfaces through which each device or switch is connected, and activate the configuration.

- Use the port world wide name (pWWN) or the node world wide name (nWWN) to specify the Nx port connection for each device.

- Use the switch world wide name (sWWN) to specify the xE port connection for each switch.

Each Nx and xE port can be configured to restrict a single port or a range of ports.

Enforcement of port security policies are done on every activation and when the port tries to come up.

The port security feature uses two databases to accept and implement configuration changes.

- Configuration database—All configuration changes are stored in the configuration database.

- Active database—The database currently enforced by the fabric. The port security feature requires all devices connecting to a switch to be part of the port security active database. The software uses this active database to enforce authorization.

About Auto-Learning

You can instruct the switch to automatically learn (auto-learn) the port security configurations over a specified period. This feature allows any switch in the Cisco MDS 9000 Family to automatically learn about devices and switches that connect to it. Use this feature when you activate the port security feature for the first time as it saves tedious manual configuration for each port. You must configure auto-learning on a per-VSAN basis. If enabled, devices and switches that are allowed to connect to the switch are automatically learned, even if you have not configured any port access.

When auto-learning is enabled, learning happens only for the devices or interfaces that were not already logged into the switch. Learned entries on a port are cleaned up after you shut down that port if auto-learning is still enabled.

Learning does not override the existing configured port security policies. So, for example, if an interface is configured to allow a specific pWWN, then auto-learning will not add a new entry to allow any other pWWN on that interface. All other pWWNs will be blocked even in auto-learning mode.

No entries are learned for a port in the shutdown state.

When you activate the port security feature, auto-learning is also automatically enabled.

Note If you enable auto-learning before activating port security, you cannot activate until auto-learning is disabled.

Port Security Activation

By default, the port security feature is not activated in any switch in the Cisco MDS 9000 Family.

By activating the port security feature, the following apply:

- Auto-learning is also automatically enabled, which means:

– From this point, auto-learning happens only for the devices or interfaces that were not logged into the switch.

– You cannot activate the database until you disable auto-learning.

- All the devices that are already logged in are learned and are added to the active database.

- All entries in the configured database are copied to the active database.

After the database is activated, subsequent device login is subject to the activated port bound WWN pairs, excluding the auto-learned entries. You must disable auto-learning before the auto-learned entries become activated.

When you activate the port security feature, auto-learning is also automatically enabled. You can choose to activate the port security feature and disable auto-learning.

Tip If a port is shut down because of a denied login attempt, and you subsequently configure the database to allow that login, the port does not come up automatically. You must explicitly issue a no shutdown CLI command to bring that port back online.

Database Activation Rejection

Database activation is rejected in the following cases:

- Missing or conflicting entries exist in the configuration database but not in the active database.

- The auto-learning feature was enabled before the activation. To reactivate a database in this state, disable auto-learning.

- The exact security is not configured for each PortChannel member.

- The configured database is empty but the active database is not.

If the database activation is rejected due to one or more conflicts listed in the previous section, you may decide to proceed by forcing the port security activation.

About Enabling Auto-learning

The state of the auto-learning configuration depends on the state of the port security feature:

- If the port security feature is not activated, auto-learning is disabled by default.

- If the port security feature is activated, auto-learning is enabled by default (unless you explicitly disabled this option).

Tip If auto-learning is enabled on a VSAN, you can only activate the database for that VSAN by using the force option.

Auto-learning Device Authorization

summarizes the authorized connection conditions for device requests.

Table 9-1 Authorized Auto-learning Device Requests

Condition

Device (pWWN, nWWN, sWWN)

Requests Connection to

Authorization

1

Configured with one or more switch ports

A configured switch port

Permitted

2

Any other switch port

Denied

3

Not configured

A switch port that is not configured

auto-learning enabled

4

auto-learning disabled

5

Configured or not configured

A switch port that allows any device

Permitted

6

Configured to log in to any switch port

Any port on the switch

Permitted

7

Not configured

A port configured with some other device

Denied

Authorization Scenarios

Assume that the port security feature is activated and the following conditions are specified in the active database:

- A pWWN (P1) is allowed access through interface fc1/1 (F1).

- A pWWN (P2) is allowed access through interface fc1/1 (F1).

- A nWWN (N1) is allowed access through interface fc1/2 (F2).

- Any WWN is allowed access through interface fc1/3 (F3).

- A nWWN (N3) is allowed access through any interface.

- A pWWN (P3) is allowed access through interface fc1/4 (F4).

- A sWWN (S1) is allowed access through interface fc1/10-13 (F10 to F13).

- A pWWN (P10) is allowed access through interface fc1/11 (F11).

.

Table 9-2 Authorization Results for Scenario

Device Connection Request

Authorization

Condition

Reason

P1, N2, F1

Permitted

1

No conflict.

P2, N2, F1

Permitted

1

No conflict.

P3, N2, F1

Denied

2

F1 is bound to P1/P2.

P1, N3, F1

Permitted

6

Wildcard match for N3.

P1, N1, F3

Permitted

5

Wildcard match for F3.

P1, N4, F5

Denied

2

P1 is bound to F1.

P5, N1, F5

Denied

2

N1 is only allowed on F2.

P3, N3, F4

Permitted

1

No conflict.

S1, F10

Permitted

1

No conflict.

S2, F11

Denied

7

P10 is bound to F11.

P4, N4, F5 (auto-learning on)

Permitted

3

No conflict.

P4, N4, F5(auto-learning off)

Denied

4

No match.

S3, F5 (auto-learning on)

Permitted

3

No conflict.

S3, F5 (auto-learning off)

Denied

4

No match.

P1, N1, F6 (auto-learning on)

Denied

2

P1 is bound to F1.

P5, N5, F1 (auto-learning on)

Denied

7

Only P1 and P2 bound to F1.

S3, F4 (auto-learning on)

Denied

7

P3 paired with F4.

S1, F3 (auto-learning on)

Permitted

5

No conflict.

P5, N3, F3

Permitted

6

Wildcard ( * ) match for F3 and N3.

P7, N3, F9

Permitted

6

Wildcard ( * ) match for N3.

About WWN Identification

If you decide to manually configure port security, be sure to adhere to the following guidelines:

- Identify switch ports by the interface or by the fWWN.

- Identify devices by the pWWN or by the nWWN.

- If an Nx port is allowed to log in to SAN switch port Fx, then that Nx port can only log in through the specified Fx port.

- If an Nx port’s nWWN is bound to an Fx port WWN, then all pWWNs in the Nx port are implicitly paired with the Fx port.

- TE port checking is done on each VSAN in the allowed VSAN list of the trunk port.

- All PortChannel xE ports must be configured with the same set of WWNs in the same PortChannel.

- E port security is implemented in the port VSAN of the E port. In this case the sWWN is used to secure authorization checks.

- Once activated, the config database can be modified without any effect on the active database.

- By saving the running configuration, you save the configuration database and activated entries in the active database. Learned entries in the active database are not saved.

Activation and Auto-learning Configuration Distribution

Activation and auto-learning configurations in distributed mode are remembered as actions to be performed when you commit the changes in the pending database.

Learned entries are temporary and do not have any role in determining if a login is authorized or not. As such, learned entries do not participate in distribution. When you disable learning and commit the changes in the pending database, the learned entries become static entries in the active database and are distributed to all switches in the fabric. After the commit, the active database on all switches are identical and learning can be disabled.

).

Table 9-3 Scenarios for Activation and Auto- learning Configurations in Distributed Mode

Scenario

Actions

Distribution = OFF

Distribution = ON

A and B exist in the configuration database, activation is not done and devices C,D are logged in.

1. You activate the port security database and enable auto-learning.

configuration database = {A,B}

active database = {A,B, C1, D*}

configuration database = {A,B}

active database = {null}

pending database = {A,B + activation to be enabled}

2. A new entry E is added to the configuration database.

configuration database = {A,B, E}

active database = {A,B, C*, D*}

configuration database = {A,B}

active database = {null}

pending database = {A,B, E + activation to be enabled}

3. You issue a commit.

Not applicable

configuration database = {A,B, E}

active database = {A,B, E, C*, D*}

pending database = empty

A and B exist in the configuration database, activation is not done and devices C,D are logged in.

1. You activate the port security database and enable auto-learning.

configuration database = {A,B}

active database = {A,B, C*, D*}

configuration database = {A,B}

active database = {null}

pending database = {A,B + activation to be enabled}

2. You disable learning.

configuration database = {A,B}

active database = {A,B, C, D}

configuration database = {A,B}

active database = {null}

learning to be disabled}

3. You issue a commit.

Not applicable

configuration database = {A,B}

active database = {A,B} and devices C and D are logged out. This is equal to an activation with auto-learning disabled.

pending database = empty

1.The * (asterisk) indicates learned entries.

1.The * (asterisk) indicates learned entries.

Tip In this case, we recommend that you perform a commit at the end of each operation: after you activate port security and after you enable auto-learning.

Database Interaction

lists the differences and interaction between the active and configuration databases.

Table 9-4 Active and Configuration Port Security Databases

Active Database

Configuration Database

Read-only.

Read-write.

Saving the configuration only saves the activated entries. Learned entries are not saved.

Saving the configuration saves all the entries in the configuration database.

Once activated, all devices that have already logged into the VSAN are also learned and added to the active database.

Once activated, the configuration database can be modified without any effect on the active database.

You can overwrite the active database with the configured database by activating the port security database. Forcing an activation may violate the entries already configured in the active database.

You can overwrite the configuration database with the active database.

Database Scenarios

Figure 9-1 depicts various scenarios to depict the active database and the configuration database status based on port security configurations.

Figure 9-1 Port Security Database Scenarios

Guidelines and Limitations

- Port security is only supported for Fibre Channel ports.

Database Merge Guidelines

A database merge refers to a union of the configuration database and static (unlearned) entries in the active database.

When merging the database between two fabrics, follow these guidelines:

- Verify that the activation status and the auto-learning status is the same in both fabrics.

- Verify that the combined number of configurations for each VSAN in both databases does not exceed 2 K.

Caution If you do not follow these two conditions, the merge will fail. The next distribution will forcefully synchronize the databases and the activation states in the fabric.

Default Settings

lists the default settings for all port security features in any switch.

Table 9-5 Default Security Settings

Parameters

Default

Auto-learn

Enabled if port security is enabled.

Port security

Disabled

Distribution

Disabled.

Note Enabling distribution enables it on all VSANs in the switch.

Configuring Port Security

The steps to configure port security depend on which features you are using. Auto-learning works differently if you are using CFS distribution.

This section includes the following topics:

- Configuring Port Security with Auto-Learning and CFS Distribution

- Configuring Port Security with Auto-Learning without CFS

- Configuring Port Security with Manual Database Configuration

- Configuring Port Security Using the Configuration Wizard

- Enabling Port Security

- Activating Port Security

- Activating the Port Security Forcefully

- Reactivating the Database

- Copying an Active Database to the Config Database

Configuring Port Security with Auto-Learning and CFS Distribution

Detailed Steps

To configure port security, using auto-learning and CFS distribution, follow these steps:

Step 1 Enable port security. See the “Enabling Port Security” section.

Step 2 Enable CFS distribution. See the “Enabling Distribution” section.

Step 3 Activate port security on each VSAN. This turns on auto-learning by default. See the “Activating Port Security” section.

Step 4 Issue a CFS commit to copy this configuration to all switches in the fabric. See the “Committing the Changes” section. At this point, all switches are activated, and auto-learning.

Step 5 Wait until all switches and all hosts are automatically learned.

Step 6 Disable auto-learn on each VSAN. See the“Disabling Auto-learning” section.

Step 7 Issue a CFS commit to copy this configuration to all switches in the fabric. See the “Committing the Changes” section. At this point, the auto-learned entries from every switch are combined into a static active database that is distributed to all switches.

Step 8 Copy the active database to the configure database on each VSAN. See the “Copying the Port Security Database” section.

Step 9 Issue a CFS commit to copy this configuration to all switches in the fabric. See the “Committing the Changes” section. This ensures that the configure database is the same on all switches in the fabric.

Step 10 Copy the running configuration to the startup configuration, using the fabric option. This saves the port security configure database to the startup configuration on all switches in the fabric.

Configuring Port Security with Auto-Learning without CFS

Detailed Steps

To configure port security using auto-learning without CFS, follow these steps:

Step 1 Enable port security. See the “Enabling Port Security” section.

Step 2 Activate port security on each VSAN. This turns on auto-learning by default. See the “Activating Port Security” section.

Step 3 Wait until all switches and all hosts are automatically learned.

Step 4 Disable auto-learn on each VSAN. See the “Disabling Auto-learning” section.

Step 5 Copy the active database to the configure database on each VSAN. See the “Copying the Port Security Database” section.

Step 6 Copy the running configuration to the startup configuration This saves the port security configure database to the startup configuration.

Step 7 Repeat Step 1 through Step 6 for all switches in the fabric.

Configuring Port Security with Manual Database Configuration

Detailed Steps

To configure port security and manually configure the port security database, follow these steps:

Step 1 Enable port security. See the “Enabling Port Security” section.

Step 2 Manually configure all port security entries into the configure database on each VSAN. See the “Configuring Port Security with Manual Database Configuration” section.

Step 3 Activate port security on each VSAN. This turns on auto-learning by default. See the “Activating Port Security” section.

Step 4 Disable auto-learn on each VSAN. See the “Disabling Auto-learning” section.

Step 5 Copy the running configuration to the startup configuration This saves the port security configure database to the startup configuration.

Step 6 Repeat Step 1 through Step 5 for all switches in the fabric.

Configuring Port Security Using the Configuration Wizard

The Port Security Configuration wizard provides step-by-step procedures for setting up the Port Security Policy for a selected VSAN. The Port Security Configuration wizard also supports the central management through CFS, making it possible to complete the entire configuration at one place.

The wizard automatically conducts few essential operations. For example, if you want central management, the wizard conducts operations to check CFS capability, enable CFS, and issue CFS commit at the proper stages.

To manage security at a particular port, you do not need to run through the wizard to configure the port security policy from the VSAN wide, but you can directly edit accesses on the port itself. This operation can be done through the Port Binding dialog box. If the port's belonging switch has not enabled port security yet, the dialog box enables security first. If the port security is enabled, the dialog box will edit the policy database based on user operations.

CFS should be enabled on all switches in the VSAN. A CFS master switch is selected to do all configurations. All changes will be distributed to the VSAN through the CFS commit command.

Prerequisites

- Enable port security on the switch.

- Define port security policy either manually by editing bound devices or switches or ports or by using autolearning.

- Activate port security policy.

- Ensure that activated and configured databases are synchronized through copy.

- Copy the activated database to be the startup configuration.

Detailed Steps

button on the toolbar.

Before launching the Port Security Setup Wizard, DCNM-SAN checks the CFS capability of the switches in the VSAN.

If VSAN context is not available, the wizard prompts to select VSAN as shown in Figure 9-2.

Figure 9-2 Select VSAN Window

.

page:

- Select the required master switch.

- Select Automatically learn all logged in ports in VSAN to Autolearn port configuration.

to proceed.

page.

Note From Cisco NX-OS Release 5.2, devices can bind to vFC interfaces.

to create port binding.

Note When interfaces are inserted for binding, vFC ports can be selected.

Step 6 Two types of port binding can be created using the Insert Port Security Devices dialog box:

- Port WWN -pWWN bound to an interface WWN.

- Switch -Switch WWN bound to an interface. (Mainly useful for ISL binding).

Step 7 Select the type of port binding by clicking the radio buttons and enter the supporting values.

to exit the Insert Port Security window.

Note To delete an entry in the Edit and Activate Configuration page of the wizard, select the entry and click the Delete button.

to complete the Port Security Configuration for the selected switch.

Enabling Port Security

By default, the port security feature is disabled in all switches in the Cisco MDS 9000 Family.

Detailed Steps

To enable port security, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables port security on that switch.

Disables (default) port security on that switch.

To enable port security, follow these steps:

Step 1 Expand a VSAN, and then select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the CFS tab.

.

Step 4 Click Apply Changes to enable CFS distribution for the port security feature.

Step 5 Click the Control tab.

You see the port security enable state for all switches in the selected VSAN.

Step 6 Set the Command column to enable for each switch in the VSAN.

Step 7 Click the CFS tab and set the Command column to commit on all participating switches in the VSAN.

Step 8 Click Apply Changes to distribute the enabled port security to all switches in the VSAN.

Activating Port Security

Detailed Steps

To activate the port security feature, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Activates the port security database for the specified VSAN, and automatically enables auto-learning.

Activates the port security database for the specified VSAN, and disables auto-learning.

Deactivates the port security database for the specified VSAN, and automatically disables auto-learning.

To activate port security, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Actions tab.

Step 3 Click in the Action column under Activation, next to the switch or VSAN on which you want to activate port security. You see a drop-down menu with the following options:

- activate —Valid port security settings are activated.

- activate (TurnLearningOff) —Valid port security settings are activated and auto-learn turned off.

- forceActivate —Activation is forced.

- forceActivate(TurnLearningOff) —Activation is forced and auto-learn is turned off.

- deactivate —All currently active port security settings are deactivated.

- NoSelection — No action is taken.

Step 4 Set the Action field you want for that switch.

Step 5 Uncheck the AutoLearn check box for each switch in the VSAN to disable auto-learning.

Step 6 Click the CFS tab and set the command column to commit on all participating switches in the VSAN.

Step 7 Click Apply Changes in DCNM-SAN or Apply in Device Manager to save these changes.

Note If required, you can disable auto-learning (see the “Disabling Auto-learning” section).

Activating the Port Security Forcefully

If the port security activation request is rejected, you can force the activation.

Note An activation using the force option can log out existing devices if they violate the active database.

command in EXEC mode.

Detailed Steps

To forcefully activate the port security database, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Forces the VSAN 1 port security database to activate despite conflicts.

To forcefully activate the port security database, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Actions tab.

option.

Step 4 Set the Action field you want for that switch.

Step 5 Click the CFS tab and set the command column to commit on all participating switches in the VSAN.

Step 6 Click Apply Changes in DCNM-SAN or Apply in Device Manager to save these changes.

Reactivating the Database

Detailed Steps

To reactivate the port security database, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Disables auto-learning and stops the switch from learning about new devices accessing the switch. Enforces the database contents based on the devices learned up to this point.

Step 3

Copies from the active to the configured database.

Step 4

Activates the port security database for the specified VSAN, and automatically enables auto-learning.

Tip If auto-learning is enabled, and you cannot activate the database, you will not be allowed to proceedwithout the force option until you disable auto-learning..

To reactivate the port security database, follow these steps:

Step 1 Disable auto-learning.

Step 2 Copy the active database to the configured database.

Tip If the active database is empty, you cannot perform this step.

Step 3 Make the required changes to the configuration database.

Step 4 Activate the database.

Copying an Active Database to the Config Database

Detailed Steps

To copy the active database to the config database, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Actions tab.

You see the switches for that VSAN.

Step 3 Check the CopyActive ToConfig check box next to the switch for which you want to copy the database.

The active database is copied to the config database when the security setting is activated.

Step 4 Uncheck the CopyActive ToConfig check box if you do not want the database copied when the security setting is activated.

Step 5 Click the CFS tab and set the command column to commit on all participating switches in the VSAN.

Step 6 Click Apply Changes to save these changes or click Undo Changes to discard any unsaved changes.

Configuring Auto-learning

This section contains the following topics:

- Enabling Auto-learning

- Disabling Auto-learning

Enabling Auto-learning

Detailed Steps

To enable auto-learning, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Enables auto-learning so the switch can learn about any device that is allowed to access VSAN 1. These devices are logged in the port security active database.

To enable auto-learning, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Actions tab.

Step 3 Click in the Action column under Activation, next to the switch or VSAN on which you want to activate port security. You see a drop-down menu with the following options:

- activate —Valid port security settings are activated.

- activate (TurnLearningOff) —Valid port security settings are activated and auto-learn turned off.

- forceActivate —Activation is forced.

- forceActivate(TurnLearningOff) —Activation is forced and auto-learn is turned off.

- deactivate —All currently active port security settings are deactivated.

- NoSelection — No action is taken.

Step 4 Select one of the port security options for that switch.

Step 5 Check the AutoLearn check box for each switch in the VSAN to enable auto-learning.

Step 6 Click the Apply Changes icon to save these changes.

Disabling Auto-learning

Detailed Steps

To disable auto-learning, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Disables auto-learning and stops the switch from learning about new devices accessing the switch. Enforces the database contents based on the devices learned up to this point.

To disable auto-learning, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Actions tab.

You see the switches for that VSAN.

Step 3 Uncheck the AutoLearn check box next to the switch if you want to disable auto-learning.

Step 4 Click the Apply Changes icon to save these changes.

Configuring Port Security Manually

This section includes the following topics:

- Task Flow for Configuring Port Security

- Adding Authorized Port Pairs

- Deleting Port Security Setting

Task Flow for Configuring Port Security

Follow these steps to configure port security on any switch in the Cisco MDS 9000 Family:

Step 1 Identify the WWN of the ports that need to be secured.

Step 2 Secure the fWWN to an authorized nWWN or pWWN.

Step 3 Activate the port security database.

Step 4 Verify your configuration.

Adding Authorized Port Pairs

Detailed Steps

To add authorized port pairs for port security, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

switch(config-port-security)#

Enters the port security database mode for the specified VSAN.

switch(config)#

Deletes the port security configuration database from the specified VSAN.

Step 3

Configures the specified sWWN to only log in through PortChannel 5.

Configures any WWN to log in through the specified interfaces.

Configures the specified pWWN to only log in through the specified fWWN.

Deletes the specified pWWN configured in the previous step.

Configures the specified nWWN to log in through the specified fWWN.

Configures the specified pWWN to log in through any port in the fabric.

Configures the specified pWWN to log in through any interface in the specified switch.

Configures the specified pWWN to log in through the specified interface in the specified switch

Configures any WWN to log in through the specified interface in any switch.

Deletes the wildcard configured in the previous step.

After identifying the WWN pairs that need to be bound, add those pairs to the port security database.

Tip Remote switch binding can be specified at the local switch. To specify the remote interfaces, you can use either the fWWN or sWWN-interface combination.

To add authorized port pairs for port security, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

Step 2 Click the Config Database tab.

Step 3 Click Create Row to add an authorized port pair.

You see the Create Port Security dialog box.

Step 4 Double-click the device from the available list for which you want to create the port security setting.

Step 5 Double-click the port from the available list to which you want to bind the device.

Step 6 Click Create to create the port security setting.

Step 7 Click the Apply Changes icon to save these changes.

Deleting Port Security Setting

Detailed Steps

To delete a port security setting from the configured database on a switch, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

Step 2 Click the Config Database tab.

You see the configured port security settings for that VSAN.

Step 3 Click the row you want to delete.

Step 4 Click Delete Row.

You see the confirmation dialog box.

Step 5 Click Yes to delete the row, or click No to close the confirmation dialog box without deleting the row.

Step 6 Click the Apply Changes icon to save these changes.

Configuring Port Security Distribution

The port security feature uses the Cisco Fabric Services (CFS) infrastructure to enable efficient database management, provide a single point of configuration for the entire fabric in the VSAN, and enforce the port security policies throughout the fabric (see Chapter 7, “Configuring IPsec Network Security”).

This section includes the following topics:

- Enabling Distribution

- Locking the Fabric

- Committing the Changes

- Discarding the Changes

Enabling Distribution

Detailed Steps

To enable the port security distribution, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Enables distribution.

Disables distribution.

command.

All the configurations performed in distributed mode are stored in a pending (temporary) database. If you modify the configuration, you need to commit or discard the pending database changes to the configurations. The fabric remains locked during this period. Changes to the pending database are not reflected in the configurations until you commit the changes.

Note Port activation or deactivation and auto-learning enable or disable do not take effect until after a CFS commit if CFS distribution is enabled. Always follow any one of these operations with a CFS commit to ensure proper configuration. See the “Activation and Auto-learning Configuration Distribution” section.

Tip In this case, we recommend that you perform a commit at the end of each operation: after you activate port security and after you enable auto learning.

To enable distribution, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Control tab.

You see the switches for that VSAN.

Step 3 In the Command column, select enable or disable from the drop-down menu.

icon to save the changes.

Locking the Fabric

The first action that modifies the existing configuration 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.

Committing the Changes

If you commit the changes made to the configurations, the configurations in the pending database are distributed to other switches. On a successful commit, the configuration change is applied throughout the fabric and the lock is released.

Detailed Steps

To commit the port security configuration changes for the specified VSAN, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Commits the port security changes in the specified VSAN.

Discarding the Changes

If you discard (abort) the changes made to the pending database, the configuration remains unaffected and the lock is released.

Detailed Steps

To discard the port security configuration changes for the specified VSAN, follow these steps:

Command

Purpose

Step 1

switch(config)#

Enters configuration mode.

Step 2

Discards the port security changes in the specified VSAN and clears the pending configuration database.

Interacting with the Database

Note You can overwrite the configuration database with the active database using the port-security database copy vsan command. The port-security database diff active vsan command in EXEC mode lists the differences between the active database and the configuration database.

This section includes the following topics:

- Copying the Port Security Database

- Deleting the Port Security Database

- Cleaning the Port Security Database

Copying the Port Security Database

Detailed Steps

command to copy from the active to the configured database. If the active database is empty, this command is not accepted.

switch# port-security database copy vsan 1

command to view the differences between the active database and the configuration database. This command can be used when resolving conflicts.

switch# port-security database diff active vsan 1

command to obtain information on the differences between the configuration database and the active database.

switch# port-security database diff config vsan 1

Tip We recommend that you copy the active database to the configuration database issue the port-security database copy vsan command after disabling auto-learning. This action ensures that the configuration database is in sync with the active database. If distribution is enabled, this command creates a temporary copy (and consequently a fabric lock) of the configuration database. If you lock the fabric, you need to commit the changes to the configuration databases in all the switches.

To copy the active database to the configuration database, follow these steps:

in the Logical Domains pane.

tab. You see all the configuration databases.

check box.

icon to save your changes.

To view the differences between the active database and the configuration database, follow these steps:

Detailed Steps

in the Logical Domains pane.

You see the Port Security information in the Information pane.

tab. You see all the configuration databases.

option to compare the differences between the selected database and the active or configuration database.

icon to save your changes.

Deleting the Port Security Database

Tip If the distribution is enabled, the deletion creates a copy of the database. An explicit deletion port-security commit command is required to actually delete the database.

Detailed Steps

command in configuration mode to delete the configured database for a specified VSAN

switch(config)# no port-security database vsan 1

To delete a port security database, follow these steps:

in the Logical Domains pane.

You see the Port Security information in the Information pane.

tab. You see all the configuration databases.

button.

if you want to delete the configuration database.

Cleaning the Port Security Database

Detailed Steps

command to clear all existing statistics from the port security database for a specified VSAN.

switch# clear port-security statistics vsan 1

command to clear any learned entries in the active database for a specified interface within a VSAN.

switch# clear port-security database auto-learn interface fc1/1 vsan 1

command to clear any learned entries in the active database for the entire VSAN.

switch# clear port-security database auto-learn vsan 1

Note The clear port-security database auto-learn and clear port-security statistics commands are only relevant to the local switch and do not acquire locks. Also, learned entries are only local to the switch and do not participate in distribution.

command to clear the pending session in the VSAN from any switch in the VSAN.

switch# clear port-security session vsan 5

To clear all existing statistics from the port security database for a specified VSAN, follow these steps:

in the Logical Domains pane.

You see the Port Security information in the Information pane.

tab.

You see all the configuration databases.

option.

To clear any learned entries in the active database for a specified interface within a VSAN, follow these steps:

in the Logical Domains pane.

You see the Port Security information in the Information pane.

tab. You see all the configuration databases.

option.

icon to save your changes.

Note You can clear the Statistics and the AutoLearn option only for switches that are local and do not acquire locks. Also, learned entries are only local to the switch and do not participate in distribution.

Verifying Port Security Configuration

To display port security configuration information, perform one of the following tasks:

Command

Purpose

Displays the Contents of the Port Security Configuration Database.

Displays the Port Security Configuration Database in VSAN 1.

show port-security database active

Displays the Activated Database.

show port-security pending vsan 1

Displays the Contents of the Temporary Configuration Database.

show port-security pending-diff vsan 1

Displays the Difference Between the Temporary Configuration Database and the Configuration Database.

show port-security database fwwn 20:85:00:44:22:00:4a:9e vsan 1

Displays the Wildcard fWWN Port Security in VSAN 1.

show port-security database fwwn 20:01:00:05:30:00:95:de vsan 1

Displays the Configured fWWN Port Security in VSAN 1.

show port-security database interface fc 1/1 vsan 2

Displays the Interface Port Information in VSAN 2.

show port-security statistics

Displays the Port Security Statistics.

show port-security status

Displays the Port Security Status.

show port-security violations

Displays the Violations in the Port Security Database.

.

- Displaying Activated Port Security Settings

- Displaying Port Security Statistics

- Displaying Port Security Violations

- Displaying Port Security Configuration

Displaying Activated Port Security Settings

To display active port security settings, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Active Database tab.

You see the active port security settings for that VSAN.

Displaying Port Security Statistics

To display port security statistics, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Statistics tab.

You see the port security statistics for that VSAN.

Displaying Port Security Violations

Port violations are invalid login attempts (for example, login requests from unauthorized Fibre Channel devices). You can display a list of these attempts on a per-VSAN basis.

To display port security violations, follow these steps:

Step 1 Expand a VSAN and select Port Security in the Logical Domains pane.

You see the port security configuration for that VSAN in the Information pane.

Step 2 Click the Violations tab. You see the port security violations for that VSAN.

Displaying Port Security Configuration

).

Example 9-1 Displays the Contents of the Port Security Configuration Database

switch# show port-security database

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

VSAN Logging-in Entity Logging-in Point (Interface)

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

1 21:00:00:e0:8b:06:d9:1d(pwwn) 20:0d:00:05:30:00:95:de(fc1/13)

1 50:06:04:82:bc:01:c3:84(pwwn) 20:0c:00:05:30:00:95:de(fc1/12)

2 20:00:00:05:30:00:95:df(swwn) 20:0c:00:05:30:00:95:de(port-channel 128)

3 20:00:00:05:30:00:95:de(swwn) 20:01:00:05:30:00:95:de(fc1/1)

[Total 4 entries]

command to view the output of the activated port security (see Example 9-2).

Example 9-2 Displays the Port Security Configuration Database in VSAN 1

switch# show port-security database vsan 1

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

Vsan Logging-in Entity Logging-in Point (Interface)

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

1 * 20:85:00:44:22:00:4a:9e (fc3/5)

1 20:11:00:33:11:00:2a:4a(pwwn) 20:81:00:44:22:00:4a:9e (fc3/1)

[Total 2 entries]

Example 9-3 Displays the Activated Database

switch# show port-security database active

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

VSAN Logging-in Entity Logging-in Point (Interface) Learnt

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

1 21:00:00:e0:8b:06:d9:1d(pwwn) 20:0d:00:05:30:00:95:de(fc1/13) Yes

1 50:06:04:82:bc:01:c3:84(pwwn) 20:0c:00:05:30:00:95:de(fc1/12) Yes

2 20:00:00:05:30:00:95:df(swwn) 20:0c:00:05:30:00:95:de(port-channel 128) Yes

3 20:00:00:05:30:00:95:de(swwn) 20:01:00:05:30:00:95:de(fc1/1)

[Total 4 entries]

Example 9-4 Displays the Contents of the Temporary Configuration Database

switch# show port-security pending vsan 1

Session Context for VSAN 1

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

Activation Status: Active

Auto Learn Status: On

Force activate: No

Config db modified: Yes

Activation done: Yes

Session owner: admin(2)

Session database:

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

VSAN Logging-in Entity Logging-in Point (Interface)

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

1 20:11:00:33:22:00:2a:4a(pwwn) 20:41:00:05:30:00:4a:1e(fc2/1)

[Total 1 entries]

Example 9-5 Displays the Difference Between the Temporary Configuration Database and the Configuration Database

switch# show port-security pending-diff vsan 1

Session Diff for VSAN: 1

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

Database will be activated

Learning will be turned ON

Database Diff:

+pwwn 20:11:00:33:22:00:2a:4a fwwn 20:41:00:05:30:00:4a:1e

).

Example 9-6 Displays the Wildcard fWWN Port Security in VSAN 1

switch# show port-security database fwwn 20:85:00:44:22:00:4a:9e vsan 1

Any port can login thru' this fwwn

Example 9-7 Displays the Configured fWWN Port Security in VSAN 1

switch# show port-security database fwwn 20:01:00:05:30:00:95:de vsan 1

20:00:00:0c:88:00:4a:e2(swwn)

Example 9-8 Displays the Interface Port Information in VSAN 2

switch# show port-security database interface fc 1/1 vsan 2

20:00:00:0c:88:00:4a:e2(swwn)

The port security statistics are constantly updated and available at any time (see Example 9-9).

Example 9-9 Displays the Port Security Statistics

switch# show port-security statistics

Statistics For VSAN: 1

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

Number of pWWN permit: 2

Number of nWWN permit: 2

Number of sWWN permit: 2

Number of pWWN deny : 0

Number of nWWN deny : 0

Number of sWWN deny : 0

Total Logins permitted : 4

Total Logins denied : 0

Statistics For VSAN: 2

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

Number of pWWN permit: 0

Number of nWWN permit: 0

Number of sWWN permit: 2

Number of pWWN deny : 0

Number of nWWN deny : 0

Number of sWWN deny : 0

...

command (see Example 9-10).

Example 9-10 Displays the Port Security Status

switch# show port-security status

Fabric Distribution Enabled

VSAN 1 :No Active database, learning is disabled, Session Lock Taken

VSAN 2 :No Active database, learning is disabled, Session Lock Taken

...

command displays the previous 100 violations by default (see Example 9-11).

Example 9-11 Displays the Violations in the Port Security Database

switch# show port-security violations

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

VSAN Interface Logging-in Entity Last-Time [Repeat count]

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

1 fc1/13 21:00:00:e0:8b:06:d9:1d(pwwn) Jul 9 08:32:20 2003 [20]

20:00:00:e0:8b:06:d9:1d(nwwn)

1 fc1/12 50:06:04:82:bc:01:c3:84(pwwn) Jul 9 08:32:20 2003 [1]

50:06:04:82:bc:01:c3:84(nwwn)

2 port-channel 1 20:00:00:05:30:00:95:de(swwn) Jul 9 08:32:40 2003 [1]

[Total 2 entries]

option displays only the specified number of entries that appear first.

Field Descriptions for Port Security

The following are the field descriptions for port security.

Port Security Actions

Field

Description

Activation

Action

- activate— Results in the valid port bindings on this VSAN/VLAN being activated.

- activate (Turn LearningOff)— Results in the valid port bindings on this VSAN/VLAN being activated and copied to the active database and will also result in auto learn being turned off on this VSAN/VLAN, once the activation is complete.

- force activate— Results in forced activation, even if there are errors during activation and the activated port bindings will be copied to the active database.

- force activate (Turn Learning Off)—Results in forced activation along with turning auto learn off after activation and the activated port bindings will be copied to the active database.

- deactivate— Results in deactivation of currently activated valid port bindings (if any), on this VSAN/VLAN. Currently active entries (if any), which would have been present in the active database, will be removed.

- Activation will not be allowed on a VSAN if auto-learn is enabled on that VSAN

Enabled

The state of activation on this VSAN/VLAN. If true, then an activation has been attempted as the most recent operation on this VSAN/VLAN. If false, then an activation has not been attempted as the most recent operation on this VSAN/VLAN.

Result

Indicates the outcome of the most recent activation/deactivation.

Last Change

When the valid port bindings on this VSAN/VLAN were last activated. If the last activation took place prior to the last re-initialization of the agent, then this value will be N/A.

CopyActiveToConfig

If enabled, results in the active port binding database to be copied on to the configuration database on this VSAN/VLAN. Note that the learned entries are also copied.

AutoLearn

Helps to learn the valid port binding configuration of devices/ports logged into the local device on all its ports and populate the above active database with the same. This mechanism of learning the configuration of devices/ports logged into the local device over a period of time and populating the configuration is a convenience mechanism for users. If enabled on a particular VSAN, all subsequent logins (FLOGIs) on that VSAN will be populated in the enforced port binding database, provided it is not in conflict with existing enforced port bindings on that VSAN. When disabled, the mechanism of learning is stopped. The learned entries will however be in the active database.

Clear AutoLearned

Action

- Clear VSAN results in port bind auto-learned entries being cleared on this VSAN.

- Clear Interface(s) results in port bind auto-learned entries being cleared on the interface specified on this VSAN.

Interface

Specifies the interface(s) on which the port bind auto-learned entries need to be cleared.

Port Security Config Database

Field

Description

Interface or fWWN

Represents the address of the port on the local device through which the device specified can FLOGI.

- If fwwn, then the value is the fabric WWN of a port on the local device.

- If intfIndex, then a port on the local device is being represented by its interface.

- If wildCard, then it represents a wild-card entry. The wild-card represents any port on the local device.

Type

The mechanism to identify a switch port.

WWN

Represents the logging-in device address.

Available Interface

Displays the available interface. The interfaces available are:

- Fibre Channel

- PortChannel

- Ethernet PortChannel

- VFC

Port Security Active Database

Field

Description

Interface or fWWN

The address of a port on the local device.

Type

The mechanism to identify a switch port.

- fwwn— The local switch port is identified by Fabric WWN(fWWN).

- intfIndex— The local switch port is identified by ifIndex.

- wildCard—Wild card (any switch port on local device).

WWN

Represents the logging-in device address.

IsLearnt

Indicates if this entry is a learned entry or not.

Port Security Database Differences

Field

Description

CompareWith

Specifies the database for the comparison.

- configDb— Compares the configuration database with respect to active database on this VSAN/VLAN. So, the active database will be the reference database and the results of the difference operation will be with respect to the active database.

- activeDb— Compares the active database with respect to configuration database on this VSAN/VLAN. So, the configuration database will be the reference database and the results of the difference operation will be with respect to the configuration database.

VSANId

The ID of the VSAN to compare against.

Interface/fWWN

The address of a port on the local device.

Type

The mechanism to identify a switch port.

- fwwn— The local switch port is identified by Fabric WWN(fWWN).

- intfIndex— The local switch port is identified by ifIndex.

- wildCard— Wild card (any switch port on local device).

WWN

Represents the logging in device address.

Reason

Indicates the reason for the difference between the databases being compared, for this entry.

Port Security Violations

Field

Description

Interface

The fWWN of the port on the local device where the login was denied.

End Device

The pWWN of the device that was denied FLOGI on one of the local device's ports.

Or Switch

The sWWN of the device (if the device happens to be a switch), that was denied entry on one of the local device's ports.

Time

When the login denial took place.

Count

The number of times this particular pWWN/nWWN or sWWN has been denied login on this particular local interface.

Port Security Statistics

Field

Description

AllowedLogins

The number of FLOGI requests that have been allowed on this VSAN/VLAN.

DeniedLogins

The number of FLOGI requests that have been denied on this VSAN/VLAN.

Clear

When set to clear, it results in port bind statistic counters being cleared on this VSAN/VLAN.

Feature History for Port Security

lists the release history for this feature. Only features that were introduced or modified in Cisco NX-OS Release 5.x or a later release appear in the table.

Remove the second sentence, above, if it does not apply to the table.

Table 9-6 Feature History for Port Security

Feature Name

Releases

Feature Information

vFC Interfaces

5.2

Devices can be bound to vFC interfaces.

Configuring Fabric Binding

This chapter describes the fabric binding feature provided in the Cisco MDS 9000 Family of directors and switches. It includes the following sections:

This chapter includes the following topics:

- Information About Fabric Binding

- Licensing Requirements for Fabric Binding

- Default Settings

- Configuring Fabric Binding

Information About Fabric Binding

The fabric binding feature ensures ISLs are only enabled between specified switches in the fabric binding configuration. Fabric binding is configured on a per-VSAN basis.

This feature helps prevent unauthorized switches from joining the fabric or disrupting current fabric operations. It uses the Exchange Fabric Membership Data (EFMD) protocol to ensure that the list of authorized switches is identical in all switches in the fabric.

This section inludes the following topics:

- Port Security Versus Fabric Binding

- Fabric Binding Enforcement

Port Security Versus Fabric Binding

compares the two features.

Table 10-1 Fabric Binding and Port Security Comparison

Fabric Binding

Port Security

Uses a set of sWWNs and a persistent domain ID.

Uses pWWNs and nWWNs or fWWNs and sWWNs.

Binds the fabric at the switch level.

Binds devices at the interface level.

Authorizes only the configured sWWN stored in the fabric binding database to participate in the fabric.

Allows a preconfigured set of Fibre Channel devices to logically connect to a SAN ports. The switch port, identified by a WWN or interface number, connects to a Fibre Channel device (a host or another switch), also identified by a WWN. By binding these two devices, you lock these two ports into a group (or list).

Requires activation on a per VSAN basis.

Requires activation on a per VSAN basis.

Allows specific user-defined switches that are allowed to connect to the fabric, regardless of the physical port to which the peer switch is connected.

Allows specific user-defined physical ports to which another device can connect.

Does not learn about switches that are logging in.

Learns about switches or devices that are logging in if learning mode is enabled.

Cannot be distributed by CFS and must be configured manually on each switch in the fabric.

Can be distributed by CFS.

Port-level checking for xE ports is as follows:

- The switch login uses both port security binding and fabric binding for a given VSAN.

- Binding checks are performed on the port VSAN as follows:

– E port security binding check on port VSAN

– TE port security binding check on each allowed VSAN

While port security complements fabric binding, they are independent features and can be enabled or disabled separately.

Fabric Binding Enforcement

To enforce fabric binding, configure the switch world wide name (sWWN) to specify the xE port connection for each switch. Enforcement of fabric binding policies are done on every activation and when the port tries to come up. In a FICON VSAN, the fabric binding feature requires all sWWNs connected to a switch and their persistent domain IDs to be part of the fabric binding active database. In a Fibre Channel VSAN, only the sWWN is required; the domain ID is optional.

Note All switches in a Fibre Channel VSAN using fabric binding must be running Cisco MDS SAN-OS Release 3.0(1) and NX-OS Release 4.1(1b) or later.

Licensing Requirements for Fabric Binding

Fabric binding requires that you install either the MAINFRAME_PKG license or the ENTERPRISE_PKG license on your switch.

See the Cisco MDS 9000 Family NX-OS Licensing Guide for more information on license feature support and installation.

Default Settings

lists the default settings for the fabric binding feature.

Table 10-2 Default Fabric Binding Settings

Parameters

Default

Fabric binding

Disabled

Configuring Fabric Binding

Detailed Steps

To configure fabric binding in each switch in the fabric, follow these steps:

Step 1 Enable the fabric configuration feature.

Step 2 Configure a list of sWWNs and their corresponding domain IDs for devices that are allowed to access the fabric.

Step 3 Activate the fabric binding database.

Step 4 Copy the fabric binding active database to the fabric binding config database.

Step 5 Save the fabric binding configuration.

Step 6 Verify the fabric binding configuration.

This section includes the following topics:

- Enabling Fabric Binding

Enabling Fabric Binding

The fabric binding feature must be enabled in each switch in the fabric that participates in the fabric binding. By default, this feature is disabled in all switches in the Cisco MDS 9000 Family. The configuration and verification commands for the fabric binding feature are only available when fabric binding is enabled on a switch. When you disable this configuration, all related configurations are automatically discarded.

Configuring Cisco TrustSec Fibre Channel Link Encryption

This chapter provides an overview of the Cisco TrustSec Fibre Channel (FC) Link Encryption feature and describes how to configure and set up link-level encryption between switches.

This chapter includes the following topics:

- Information About Cisco TrustSec FC Link Encryption

- Guidelines and Limitations

- Configuring Cisco TrustSec Fibre Channel Link Encryption

- Configuring ESP Settings

- Verifying Cisco TrustSec Fibre Channel Link Encryption Configuration

Information About Cisco TrustSec FC Link Encryption

Cisco TrustSec FC Link Encryption is an extension of the Fibre Channel-Security Protocol (FC-SP) feature and uses the existing FC-SP architecture to provide integrity and confidentiality of transactions. Encryption is now added to the peer authentication capability to provide security and prevent unwanted traffic interception. Peer authentication is implemented according to the FC-SP standard using the Diffie-Hellman Challenge Handshake Authentication Protocol (DHCHAP) protocol.

Note Cisco TrustSec FC Link Encryption is currently only supported between Cisco MDS switches. This feature is not supported when you downgrade to software versions which do not have the Encapsulating Security Protocol (ESP) support.

This section includes the following topics:

- Supported Modules

- Cisco TrustSec FC Link Encryption Terminology

- Support for AES Encryption

Supported Modules

The following modules are supported for the Cisco TrustSec FC Link Encryption feature:

- 1/2/4/8 Gbps 24-Port Fibre Channel switching module (DS-X9224-96K9)

- 1/2/4/8 Gbps 48-Port Fibre Channel switching module (DS-X9248-96K9)

- 1/2/4/8 Gbps 4/44-Port Fibre Channel switching module (DS-X9248-48K9)

Cisco TrustSec FC Link Encryption Terminology

The following Cisco TrustSec FC Link Encryption-related terms are used in this chapter:

- Galois Counter Mode (GCM)—A block cipher mode of operation providing confidentiality and data-origin authentication.

- Galois Message Authentication Code (GMAC)—A block cipher mode of operation providing only data-origin authentication. It is the authentication-only variant of GCM.

- Security Association (SA)—A connection that handles the security credentials and controls how they propagate between switches. The SA includes parameters such as salt and keys.

- Key—A 128-bit hexadecimal string that is used for frame encryption and decryption. The default value is zero.

- Salt —A 32-bit hexadecimal number that is used during encryption and decryption. The same salt must be configured on both sides of the connection to ensure proper communication. The default value is zero.

- Security Parameters Index (SPI) number—A 32-bit number that identifies the SA to be configured to the hardware. The range is from 256 to 4,294,967,295.

Support for AES Encryption

The Advanced Encryption Standard (AES) is the symmetric cipher algorithm that provides a high-level of security, and can accept different key sizes.

The Cisco TrustSec FC Link Encryption feature supports the 128-bit AES for security encryption and enables either AES-GCM or AES-GMAC for an interface. The AES-GCM mode provides encryption and authentication of the frames and AES-GMAC provides only the authentication of the frames that are being passed between the two peers.

Guidelines and Limitations

This section lists the guidelines for Cisco TrustSec FC Link Encryption:

- Ensure that Cisco TrustSec FC Link Encryption is enabled only between MDS switches. This feature is supported only on E-ports or the ISLs, and errors will result if non-MDS switches are used.

- Ensure that the peers in the connection have the same configurations. If there are differences in the configurations, a “port re-init limit exceeded” error message is displayed.

- Before applying the SA to the ingress and egress hardware of a switch interface, ensure that the interface is in the admin shut mode.

Configuring Cisco TrustSec Fibre Channel Link Encryption

This section includes the following topics:

- Enabling Cisco TrustSec FC Link Encryption

- Setting Up Security Associations

- Setting Up Security Association Parameters

Enabling Cisco TrustSec FC Link Encryption

By default, the FC-SP feature and the Cisco TrustSec FC Link Encryption feature are disabled in all switches in the Cisco MDS 9000 Family.

You must explicitly enable the FC-SP feature to access the configuration and verification commands for fabric authentication and encryption. When you disable this feature, all related configurations are automatically discarded.

Detailed Steps

To enable FC-SP for a Cisco MDS switch, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Enables the FC-SP feature.

Disables (default) the FC-SP feature in this switch.

Setting Up Security Associations

To perform encryption between the switches, a security association (SA) needs to be set up. An administrator manually configures the SA before the encryption can take place. The SA includes parameters such as keys and salt, that are required for encryption. You can set up to 2000 SAs in a switch.

Detailed Steps

To set up an SA between two switches, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

switch(config)# fcsp esp sa spi_number

Enters into SA submode for configuring SAs. The range of spi_number is from 256 to 4294967295.

Step 3

switch(config)# no fcsp esp sa spi_number

Deletes the SA between the switches.1

1.If the specified SA is currently programmed to the ports, this command returns an error saying that the SA is in use.

1.If the specified SA is currently programmed to the ports, this command returns an error saying that the SA is in use.

To determine which ports are using the SA, use the show running-config fcsp command. Refer to the “Displaying Running System Information” section.

Note Cisco TrustSec FC Link Encryption is currently supported only on DHCHAP on and off modes.

Setting Up Security Association Parameters

Detailed Steps

To set up the SA parameters, such as keys and salt, follow these steps:

Command

Purpose

Step 1

Enters configuration mode.

Step 2

Step 3

Step 4

switch(config)# fcsp esp sa spi_number

Enters into SA submode for configuring SAs. The range of spi_number is from 256 to 4294967295.

Configures the key for the SA. Maximum size of key is 34.

Step 5

Removes the key from the SA.

Step 6

Configures the salt for the SA. The range is from 0x0 to 0xffffffff.

Step 7

Removes the salt for the SA.

To set up the SA parameters, such as keys and salt, using DCNM-SAN, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP (DHCHAP).

You see the FC-SP configuration in the Information pane.

Step 2 Click the SA tab.

You see the SA parameters for each switch.

Step 3 Click the Create Row icon.

You see the Create SA Parameters dialog box.

Step 4 Select the switches on which you want to perform an encryption.

Step 5 Select a value for the SP. The range is from 256 to 65536.

Step 6 Enter a value for the salt. Alternatively, click Salt Generator to select a value

Step 7 Enter a value for the key. Alternatively, click Key Generator to select a value.

Step 8 Click Create to save the changes.

To set up the SA parameters, such as keys and salt, using Device Manager, follow these steps:

Step 1 Choose Switches > Security, and then select FC-SP.

You see the FC-SP configuration dialog box.

Step 2 Click the SA tab.

You see the SA parameters for each switch.

Step 3 Click Create to create new parameters.

You see the Create FC-SP SA dialog box.

Step 4 Select a value for the SP. The range is from 256 to 65536.

Step 5 Enter a value for the salt. Alternatively, click Salt Generator to select a value

Step 6 Enter a value for the key. Alternatively, click Key Generator to select a value.

Step 7 Click Create to save the changes.

Configuring ESP Settings

This section includes the following topics:

- Configuring ESP on Ingress and Egress Ports

- Configuring ESP Modes

Configuring ESP on Ingress and Egress Ports

Once the SA is created, you need to configure Encapsulating Security Protocol (ESP) on the ports. You should specify the egress and ingress ports for the encryption and decryption of packets between the network peers. The egress SA specifies which keys or parameters are to be used for encrypting the packets that leave the switch. The ingress SA specifies which keys or parameters are to be used to decrypt the packets entering that particular port.

This section covers the following topics:

- Configuring ESP on Ingress Port

- Configuring ESP on Egress Ports

Configuring ESP on Ingress Port

Detailed Steps

To configure SA to the ingress hardware, follow these steps:

Step 1

Step 2

Step 3

switch# config t

Enters the configuration mode.

switch(config)# interface fc x/y

Configures the FC interface on slot x, port y.

switch(config-if)# fcsp esp manual

Enters the ESP configuration submode.

Step 4

switch(config-if)# ingress-sa spi_number

Configures the SA to the ingress hardware.

Step 5

switch(config-if)# no ingress-sa spi_number

Removes the SA from the ingress hardware.2

2.If SA is not configured in the ingress port, then running this command returns an error message.

2.If SA is not configured in the ingress port, then running this command returns an error message.

Configuring ESP on Egress Ports

Detailed Steps

To configure SA to the egress hardware, follow these steps:

Step 1

Step 2

Step 3

switch# config t

Enters the configuration mode.

switch(config)# interface fc x/y

Configures the FC interface on slot x, port y.

switch(config-if)# fcsp esp manual

Enters the ESP configuration submode.

Step 4

switch(config-if)# egress-sa spi_number

Configures the SA to the egress hardware.

Step 5

switch(config-if)# no egress-sa spi_number

Removes the SA from the egress hardware.3

3.If SA is not configured in the egress port, then running this command returns an error message.

3.If SA is not configured in the egress port, then running this command returns an error message.

Note To apply the SA to the ingress and egress hardware of an interface, the interface needs to be in the admin shut mode.

Configuring ESP Modes

Configure the ESP settings for the ports as GCM to enable message authentication and encryption or as GMAC to enable message authentication.

The default ESP mode is AES-GCM.

This section covers the following topics:

- Configuring AES-GCM

- Configuring AES-GMAC

Configuring AES-GCM

Detailed Steps

To configure the AES-GCM mode, follow these steps:

Command

Purpose

Step 1

switch# config t

Enters the configuration mode.

Step 2

Step 3

Step 4

switch(config)# interface fc x/y

Configures the FC interface on slot x, port y.

switch(config-if)# fcsp esp manual

Enters the ESP configuration submode to configure the ESP settings on each port.

Step 5

switch(config-if-esp)# mode gcm

Sets the GCM mode for the interface.

Configuring AES-GMAC

Detailed Steps

To configure AES-GMAC mode, follow these steps:

Command

Purpose

Step 1

switch# config t

Enters the configuration mode.

Step 2

Step 3

Step 4

switch(config)# interface fc x/y

Configures the FC interface on slot x, port y.

switch(config-if)# fcsp esp manual

Enters the ESP configuration submode to configure the ESP settings on each port.

Step 5

switch(config-if-esp)# mode gmac

Sets the GMAC mode for the interface.

Step 6

switch(config-if-esp)# no mode gmac

Removes the GMAC mode from the interface and applies the default AES-GCM mode.

Note The ESP modes are set only after a SA is configured to either the ingress or the egress hardware. If SA has not been configured, ESP is turned off and encapsulation does not occur.

Note An ESP mode change always needs a port flap because the change is not seamless if it is done after you configure the port; although the configurations are not rejected.

Detailed Steps

To configure ESP settings, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP (DHCHAP).

You see the FC-SP configuration in the Information pane.

Step 2 Click the ESP Interfaces tab.

You see the Interface details for each switch.

Step 3 Click the Create Row icon.

You see the Create ESP Interfaces dialog box.

Step 4 Select the switches on which you want to perform an encryption.

Step 5 Enter an interface for the selected switch.

Step 6 Select the appropriate ESP mode for the encryption.

Step 7 Enter the appropriate egress port for the encryption.

Step 8 Enter the appropriate ingress port for the encryption.

Step 9 Click Create to save the changes.

To configure ESP settings using Device Manager, follow these steps:

Step 1 Expand Switches > Security, and then select FC-SP.

You see the FC-SP configuration dialog box.

Step 2 Click the ESP Interfaces tab.

You see the Interface details for each switch.

Step 3 Click Create.

You see the Create FC-SP ESP Interfaces dialog box.

Step 4 Enter an interace for any switch for encryption. Alternatively, you can select values from the available interfaces for the selected switch.

Step 5 Select the appropriate ESP mode for the encryption.

Step 6 Enter the appropriate egress port for the encryption.

Step 7 Enter the appropriate ingress port for the encryption.

Step 8 Click Create to save the changes.

Configuring ESP Using ESP Wizard

You can configure and set up link-level encryption between switches using ESP wizard. You can configure an existing Inter-Switch Link (ISL) as a secure ISL or edit an existing secure ingress SPI and egress SPI using this wizard.

Detailed Steps

To configure ESP using ESP wizard, follow these steps:

Step 1 Right-click Tools > Security> FC-SP ESP Link Security to launch the ESP wizard from DCNM-SAN.

Step 2 Select the appropriate ISL to secure or edit security.

Note Only ISLs with FC-SP port mode turned on and available on ESP- capable switches or blades are displayed.

Step 3 Create new Security Associations (SAs).

You can create a new SA for each switch or use the existing SAs. You can click View Existing SA to view the existing SAs.

Note The existing list of SAs displays all existing SAs for a switch. The wizard runs only when a pair of switches have a common SA. The wizard checks for this requirement when you select Next and a warning message is displayed if a pair of switches do not have a common SA. You must create a common SA on the pair of the switches to run this wizard.

Step 4 Specify the Egress port, Ingress port, and ESP mode for the selected ISL.

The Egress and Ingress ports are auto populated with SPIs of the SAs common to a pair of switches incase of a secured ISL.

In this scenario, the mode is disabled and you cannot edit the modes for a secured ISL.

Note You can modify an existing ESP configuration provided the selected ISLs are enabled.

Step 5 Review your configuration.

Step 6 Click Finish to start the configuration for the ESP setup. You can view the status of the configuration in the status column.

Changing Keys for Switches

After the SA is applied to the ingress and egress ports, you should change the keys periodically in the configuration. The keys should be changed sequentially to avoid traffic disruption.

As an example, consider that a security association has been created between two switches, Switch1 and Switch2. The SA is configured on the ingress and egress ports as shown in the following example:

switch# config t

switch(config)# interface fc1/1

switch(config-if)# fcsp esp manual

switch(config-if)# ingress-sa 256

switch(config-if)# egress-sa 256

Detailed Steps

To change the keys for these switches, follow these steps:

Step 1 Add a new SA on Switch1 and Switch2.

switch# config t

switch(config)# fcsp esp sa 257

switch(config-sa)# key 0xAC9EF8BC8DB2DBD2008D184F794E0C38

switch(config-sa)# salt 0x1234

Step 2 Configure the ingress SA on Switch1.

switch# config t

switch(config)# interface fc1/1

switch(config-if)# fcsp esp manual

switch(config-if)# ingress-sa 257

Step 3 Configure the ingress and the egress SA on Switch2.

switch# config t

switch(config)# interface fc1/1

switch(config-if)# fcsp esp manual

switch(config-if)# ingress-sa 257

switch(config-if)# egress-sa 257

Step 4 Configure the egress SA on Switch1.

switch# config t

switch(config)# interface fc1/1

switch(config-if)# fcsp esp manual

switch(config-if)# egress-sa 257

Step 5 Remove the previously configured ingress SA from both the switches.

switch# config t

switch(config)# interface fc1/1

switch(config-if)# fcsp esp manual

switch(config-if)# no ingress-sa 256

Verifying Cisco TrustSec Fibre Channel Link Encryption Configuration

You can view information about the Cisco TrustSec FC Link Encryption feature using the show commands in DCNM-SAN or Device Manager.

Command

Purpose

Displays all FC-SP-related information for a specific interface.

show running-config fcsp

Displays all the run-time information relevant to FC-SP.

show fcsp interface fc3/31 statistics

Displays all statistics related to DHCHAP and ESP for an interface.

.

This section has the following topics:

- “Displaying FC-SP Interface Information” section

- “Displaying Running System Information” section

- “Displaying FC-SP Interface Statistics” section

- Displaying FC-SP Interface Statistics

- Displaying FC-SP Interface Statistics Using Device Manager

Displaying FC-SP Interface Information

Use the show fcsp interface command to show all FC-SP-related information for a specific interface.

switch# show fcsp interface fc7/41

fc7/41:

fcsp authentication mode:SEC_MODE_OFF

ESP is enabled

configured mode is: GCM

programmed ingress SA: 300, 303

programmed egress SA: 300

Status:FC-SP protocol in progress

Displaying Running System Information

Use the show running-config fcsp command to show all the run-time information relevant to FC-SP. All details about ESP and configured interfaces are displayed. Use this command to determine which ports are using SA.

switch# show running-config fcsp

version 4.1(2)

feature fcsp

fcsp esp sa 300

key 0x00000000000000000000000000123456

salt 0x123456

fcsp esp sa 301

key 0x00000000000000000000000000123456

salt 0x1234567

fcsp esp sa 302

key 0x00000000000000000000000000123456

salt 0x123456

interface fc8/48

fcsp off

fcsp esp manual

ingress-sa 300

ingress-sa 301

egress-sa 300

Displaying FC-SP Interface Statistics

Use the show fcsp interface statistics command to show all statistics related to DHCHAP and ESP for an interface. The ESP statistics shown depend on the ESP supported by the port ASIC.

switch# show fcsp interface fc3/31 statistics

fc7/41:

fcsp authentication mode:SEC_MODE_ON

ESP is enabled

configured mode is: GMAC

programmed ingress SA: 256, 257

programmed egress SA: 256

Status:Successfully authenticated

Authenticated using local password database

Statistics:

FC-SP Authentication Succeeded:17

FC-SP Authentication Failed:3

FC-SP Authentication Bypassed:0

FC-SP ESP SPI Mismatched frames:0

FC-SP ESP Auth failed frames:0

Displaying FC-SP Interface Statistics

You can view the statistics data that displays the Encapsulating Security Protocol-ESP Security Parameter (SPI) mismatches and Interface-Encapsulating Security Protocol authentication failures information using DCNM-SAN.

To view the ESP statistics for an interface, follow these steps:

Step 1 Expand Interfaces > FC Physical, and then select FC-SP.

You see the FC-SP configuration in the Information pane.

Step 2 Click the FC-SP tab.

You see view the FC-SP statistics data in the Information pane.

Step 3 Click Refresh to refresh the statistics data.

Displaying FC-SP Interface Statistics Using Device Manager

To view the ESP statistics for an interface using Device Manager, follow these steps:

Step 1 Choose Security > FC Physical, and then select FC-SP.

You see the FC-SP configuration in the Information pane.

Step 2 Click the Statistics tab.

You see the statistics in the Information pane.

Step 3 Click Refresh to refresh the statistics data.

Cisco Prime DCNM for SAN, Security Configuration Guide, Release 7.0.x

April, 2015

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2015 Cisco Systems, Inc. All rights reserved.