Storage security, best practices, and support information Related

Storage security, best practices, and support
information
The following chapters describe storage security and SAN best practices:
•
Storage security on page 398
•
Best practices on page 415
Related information
Table 182: Related documentation
Topic
Information source
Switches
For the latest information on B-series, C-series, and H-series switches
and firmware versions, see the SAN Infrastructure website:
http://www.hpe.com/info/StoreFabric
Fabric interoperability
HPE StorageWorks Fabric Interoperability: Merging Fabrics Based on Cseries and B-series Fibre Channel Switches Application Notes
See this document on the SAN Infrastructure website:
http://www.hpe.com/info/StoreFabric
HPE Data Availability,
Protection and Retention
The HPE solution is the HPE Data Availability, Protection and Retention
Compatibility Matrix (www.hpe.com/storage/daprcompatibility).
Storage arrays
For the latest information on storage arrays, see the Disk Storage
Systems website:
http://www.hpe.com/storage/disk-storage
Storage security, best practices, and support information
397
Storage security
This chapter describes storage security best practices. It describes the following topics:
•
Storage security threats on page 398
•
Storage security compliance on page 400
•
Security technologies on page 401
•
HPE security strategy on page 403
•
Storage security best practices on page 405
•
Assessing security risks on page 405
•
HPE storage security solutions on page 406
Storage security threats
Securing SAN environments has become an increasingly important aspect of data security. IT
organizations face many security threats and must comply with numerous industry and government
regulations. In the past, IT organizations accepted that authentication issues were handled by the network
architecture; they were not responsible for SAN security.
The NSA IATF defines five security attack classes that you should consider when defining your solution.
398
Storage security
Table 178: Security attack classes
Attack class
Description
Passive
Attacks that can disclose information to an attacker.
Passive attacks include:
•
Analyzing traffic
•
Monitoring unprotected communications
•
Decrypting weakly encrypted traffic
•
Capturing authentication information (passwords)
An example of a passive attack is the disclosure of information such as credit card
numbers and passwords.
Active
Attacks that can disclose information, deny service, or modify data.
Active attacks include:
Close-in
•
Attempting to circumvent or break protection features
•
Introducing malicious code
•
Stealing or modifying information
•
Attacking a network backbone
•
Exploiting in-transit information
•
Penetrating an enclave
•
Attacking when a remote user attempts to connect to an enclave
Attacks by an unauthorized user who is in close physical proximity to networks,
systems, or facilities. The user may attempt to gather or modify information, or deny
authorized users access to information.
Table Continued
Storage security
399
Attack class
Description
Insider
Unauthorized attacks by an authorized user can be malicious or nonmalicious.
Malicious attackers can:
•
Eavesdrop
•
Steal or damage data
•
Use data for fraudulent purposes
•
Deny authorized users access
Nonmalicious attacks can result from:
Distribution
•
Carelessness
•
Lack of knowledge
•
Circumventing security for nonmalicious purposes to perform tasks
Attacks due to modifications to hardware or software made at the factory or during
distribution. Distribution attacks can insert malicious code in a product, which can allow
future unauthorized access to the system.
Storage security compliance
Compliance ensures that a storage system meets specific criteria established by law or regulation.
Retention of electronic records is mandated by statutory and regulatory law.
Data security regulations are enacted by international governments and U.S. federal and state
governments. All storage systems must comply with local regulations.
Table 179: U.S. and international security regulations
U.S. federal and state regulations
International regulations
•
Sarbanes-Oxley (SOX) Act of 2002
•
•
Gramm-Leach-Bliley Act (GLBA) of 1999
European Union Data Protection Directive of
1995
•
Securities and Exchange Commission Act
(SEC) rules 17a-3 and 17a-4
•
Canada: Personal Information Protection and
Electronic Documents Act (PIPEDA)
•
Department of Energy (DOE) 10 CFR 600.153
Retention and access requirements for records •
Australia: Privacy Act 1988
•
California Data Security Act (SB 1386/AB
1950)
•
UK: Data Protection Act 1998
•
New Zealand: Privacy Act 1993
•
New York Regulation 173 Standards for
safeguarding customer information
•
400
Storage security compliance
Japan: Personal Information Protection Act
Security technologies
This section describes security technologies for IP SAN, Fibre Channel SAN, and encryption.
IP SAN security technologies
IP SAN technologies includes NAS, iSCSI, and FCIP. IP SAN security is achieved through the following:
•
CHAP
•
IPsec
CHAP
CHAP uses a three-way handshake to ensure validity of remote clients. It is more secure than the PAP. A
summary of the CHAP process follows:
•
When the server is first connected, it sends a challenge message to the peer.
•
The peer responds by sending a value generated by a one-way hash function.
•
The server compares this value to its own generated value.
•
If the values match, the connection is allowed to continue; if they do not match, the connection is
terminated.
•
To ensure the validity of the peer, the server sends challenge messages at random intervals and
changes the CHAP identifiers frequently.
IPsec
IPsec uses an open-standards framework to protect data transmission over IP networks. It uses
cryptographic security services.
IPsec supports:
•
Network-level peer authentication
•
Data-origin authentication
•
Data integrity
•
Data encryption
•
Replay protection
Microsoft bases its IPsec implementation on the standards developed by the IETF IPsec working group.
Fibre Channel SAN security technologies
Fibre Channel SAN security is achieved through the FC-SP.
FC-SP
FC-SP protects in-transit data—It does not protect data stored on the Fibre Channel network. FC-SP is a
project of the Technical Committee T11, within the International Committee for Information Technology
Standards, which is responsible for developing Fibre Channel interfaces (see http://www.t11.org).
FC-SP uses:
Security technologies
401
•
Authentication of Fibre Channel devices (device-to-device authentication)
•
Cryptographically secure key exchange
•
Cryptographically secure communication between Fibre Channel devices
Encryption security technologies
Encryption security is achieved through the DES, AES, and key management.
Data Encryption Standard
DES is a block cipher designed for use in symmetric cryptography, which encrypts data in 64-bit blocks
and uses a key length of 56 bits. It uses a 64-bit key, but every eighth bit is ignored. These extra bits can
be used for other purposes, such as a parity check to ensure that the key is error free.
The DES cipher consists of the following process:
Procedure
1. Performing an initial permutation
2. Breaking the block into right and left halves (32 bits each, followed by 16 key-dependent rounds on
each half)
3. Rejoining of the halves
4. Performing the final permutation (reverse of the initial permutation)
Two common DES cipher modes are as follows:
•
ECB
—Each block of the message is encrypted independently.
•
CBC
—Each plaintext block uses an Exclusive–OR operation with the previous cipher text block before
encryption.
Advanced Encryption Standard
AES is a block cipher designed for use in symmetric cryptography, which encrypts data in 128-bit blocks.
AES can use a key size of 128, 192, or 256 bits. The number of rounds varies by the key length (for
example, 10, 12, or 14 rounds for key sizes 128, 192, or 256, respectively). The processing in each round
is more efficient than DES and is better suited to high-speed parallel operations. A subkey step using an
XOR operation, followed by a MixColumns step, occurs before the rounds are performed.
AES has equivalent modes to the ECB and CBC modes for DES. AES also has a counter mode in which
a sequence number uses an Exclusive-XOR operation with the plaintext before processing; the sequence
number is incremented for use with the next block.
Key management
Successful key management is the most important yet most difficult aspect of a cryptographic system
because it often requires coordination between departments and users, and the establishment and
enforcement of strict system policies. You must ensure the generation, storage, exchange, verification,
replacement, and destruction of keys.
402
Encryption security technologies
Organizational security policies
Organizational security policies are high-level statements that define the data protection requirements,
which are driven by business needs. Auditing and reporting policies are added to the security policies,
and the business policies are then mapped to the security policies.
HPE security strategy
This section describes the HPE Secure Advantage, the HPE security strategy.
HPE Secure Advantage
Secure Advantage allows you to combine HPE security products. The Secure Advantage portfolio
ensures secure automation, optimization, and acceleration of your infrastructure with proper validation to
reduce risk and improve business outcomes. Hewlett Packard Enterprise provides solutions in information
security, identity management, key management, and compliance to ensure your enterprise security.
Secure Advantage builds on these existing security technologies to create manageable methods for you
to leverage encryption and key management. This allows you to protect your resources and validate
compliance with government and industry regulations.
Security is an important aspect of the HPE Adaptive Infrastructure, which provides the platform for the
next-generation data center. Secure Advantage integrates with Adaptive Infrastructure enablers, such as
IT systems and services, power and cooling, virtualization, and automation.
The Secure Advantage portfolio considers three aspects to ensure storage security:
•
Resource protection
•
Data protection
•
Security validation
Resource protection
Resource protection is important to your security strategy. Using trusted platforms, you improve
availability and provide protection for networks, software, and database management systems. Access
control in a trusted and hardened infrastructure minimizes disruptions due to security breaches.
Access control
Access control prevents unauthorized use of network resources and unauthorized disclosure or
modification of data (for example, preventing users from logging in to local workstations or limiting the use
of dial-in modems). Access control is a set of controls: confidentiality, integrity, availability, and limiting
access to network resources. These depend on the successful prevention of unauthorized access to
services or information.
Important elements of access control include:
•
Identification
—Identifies an entity (user, process, or role associated with multiple users)
•
Authorization
—Determines the access rights of an entity (with a level of assurance)
•
Authentication
—Authenticates a user or process
•
Enforcement
Organizational security policies
403
—Applies access-control decisions, which provides protection
Data protection
Data protection is important for all data states: at-rest, in-transit, and in-use. Use encryption and identity
management in conjunction with other proactive techniques, such as security event management and
information management.
Data protection consists of the following:
•
Confidentiality
•
Data integrity
•
Data availability
•
Nonrepudiation
Confidentiality
Confidentiality prevents disclosure of all data, regardless of its state (at-rest, in-transit, or in-use).
Confidentiality needs vary depending on the amount and type of data, transit and storage locations, and
sensitivity of the end-user identity.
Important elements of confidentiality include:
•
Data encryption
—Invokes mechanisms that act in response to characteristics of the data, not in response to a threat.
•
Data separation
—Provides separate paths for data or processing. The level of security for data separation depends on
the trust level associated with the system. Data separation ensures confidentiality by preventing data
from reaching unauthorized users.
•
Traffic separation
—Adds meaningless random information and hides network-layer addresses. Traffic separation
ensures confidentiality by making it difficult to determine data characteristics, such as frequency and
traffic-flow destinations.
Data integrity
Data integrity prevents unauthorized modification or destruction of data and ensures nonrepudiation and
authenticity. Recording all changes to data enables the detection and notification of unauthorized
modifications.
Data integrity has two types of data:
•
Single-unit data
—Applied to a single piece of data
•
Data stream
—Applied to all PDUs
Data availability
Data availability ensures reliable access to data and information services for authorized users in the SAN.
You must protect your data from attacks, unauthorized use, and routine failures.
Nonrepudiation
404
Data protection
Nonrepudiation ensures that all parties in a transaction are authenticated and verifies that they
participated in the transaction. Storage technologies are tied closely with data and are often the last line
of defense against attacks.
Security validation
Security validation establishes a secure audit trail across your organization. The audit trail serves as proof
of compliance for internal and external audits with real-time alerts. Validation is accomplished using
encryption, key management, and identity management, which creates an integrated compliance solution
across the organization.
To ensure compliance, every process you use must be repeatable, have demonstrated control points
(with documented responsible personnel), and include a tamper-proof audit tracking system.
Storage security best practices
To simplify storage security, the SNIA SSIF has developed the following security elements:
•
Storage system security
—Secures embedded operating systems and applications. Integrates with IT and security
infrastructure, such as external authentication services, centralized logging, and firewalls.
•
SRM
—Securely provisions, monitors, tunes, reallocates, and controls storage resources to ensure storage
and retrieval of data.
•
Data in-flight
—Protects the confidentiality, integrity, and availability of data as it is transferred across the SAN, LAN,
or WAN. This may also include traffic management.
•
Data at-rest
—Protects the confidentiality, integrity, and availability of data stored on servers, storage arrays, NAS
appliances, tape libraries, and other media. The measures required depend on the type of risk you are
managing.
•
Compliance validation
—Proof of compliance is required by government and industry regulations. You must establish control
points that ensure repeatable processes, assignment of responsibilities, and role separation. You must
be able to prove that policies are being enforced for internal and external audits.
Assessing security risks
This section describes best practices for assessing and addressing security risks.
Managing organizational risks
Managing organizational risks involves the following actions:
•
Protecting IT resources
•
Protecting data in all states (at-rest, in-transit, or in-use)
•
Providing validation to internal and external auditors
The Secure Advantage solution addresses these security issues using a suite of integrated products.
Integration of encryption and key management technologies with identity management in a hardened
Security validation
405
infrastructure ensures that the correct data is delivered to the intended users. Secure Advantage provides
the best layered end-to-end security approach with identity management at the network, system, service,
and application layers. It ensures a robust and proactive security framework.
Data security implementations
Data security implementations are categorized as follows:
•
Storage network
—Consists of switches, appliances, and cables. Switches and appliances come with support to protect
themselves. The storage network components support key management, encryption services, and
authentication of server and storage arrays.
•
Servers
—Consists of hardware, operating systems, interface cards (NICs and HBAs), and applications (also
known as hosts). Each component comes with support for protecting itself. The interfaces cards
support authentication and secure tunnel.
•
Storage arrays
—Consists of groups of disks or tapes that use a management application, which protects the
resources through authentication. Storage arrays will support native encryption in the future.
HPE storage security solutions
This section describes HPE storage security solutions for the following products:
•
C-series Storage Media Encryption on page 406
•
C-series SAN-OS security on page 407
•
C-series IP SAN security on page 408
•
B-series Encryption Switch and Encryption FC Blade security on page 409
•
B-series Fabric OS security on page 410
•
Key management on page 414
C-series Storage Media Encryption
SME is a standards-based encryption solution for heterogeneous and virtual tape libraries. SME is
managed with the Cisco Fabric Manager web client and a command-line interface, which supports unified
SAN management and security provisioning. SME is a comprehensive network-integrated encryption
service with key management that works transparently with new and existing SANs. This solution has
advantages over competitive solutions, such as:
406
•
Supports nondisruptive installation and provisioning. You do not need to rewire or reconfigure your
SAN.
•
Encryption engines are integrated on the MDS 9000 18/4-port Multiservice Module (MSM-18/4) and
the MDS 9222i Multiservice Fabric Switch. You do not need to purchase and manage additional switch
ports, cables, and applications.
Data security implementations
•
All VSAN traffic can be encrypted. This enables automated load balancing through network traffic
management across multiple SANs.
•
No additional software is required for key and user management or provisioning. SME is integrated
with the Cisco Fabric Manager, which reduces operating expenses.
Features
Management features of the Cisco Fabric Manager are as follows:
•
Transparent fabric service
•
Encryption
•
Security roles
•
Key management
•
Clustering
•
Fibre Channel redirect
•
Host-based discovery for provisioning tapes
Hardware requirements
SME requires a minimum of one MDS 9222i switch or one MSM-18/4 module in each cluster. The SME
engines on the switch or module provide transparent encryption and compression to hosts and storage
devices. A smart card reader is required to take advantage of all of the standard and advanced security
levels.
C-series SAN-OS security
This section describes the C-series SAN-OS security features.
Simple Network Management Protocol
SNMP is an application-layer protocol that facilitates the exchange of management information between
network devices. C-series switches support the following SNMP versions:
•
SNMP v1 and SNMP v2c
—Use a community-string match for user authentication.
•
SNMP v3
—Provides secure access to devices by using the following:
◦
Message integrity
—Ensures that a packet has not been tampered with while in transit
◦
Authentication
—Confirms that the message comes from a valid source
◦
Encryption
—Scrambles the packet contents, which prevents unauthorized viewing
Remote Authentication Dial-In User Service
C-series SAN-OS security
407
RADIUS is a distributed client-server protocol that protects networks against unauthorized access.
RADIUS clients run on C-series switches and send authentication requests to a central RADIUS server,
which contains all user authentication and network service information.
Terminal Access Controller Access Control System
TACACS+ is a client-server protocol that uses TCP for transport. All C-series switches provide centralized
authentication using TACACS+, which provides:
•
Independent, modular AAA facilities
•
Reliable transfers by using TCP to send data between the AAA client and server
•
Encryption of all data between the switch and AAA server, which ensures data confidentiality (RADIUS
encrypts passwords only)
FC-SP and Diffie-Hellman CHAP
FC-SP provides switch-to-switch and host-to-switch authentication, which provides security challenges for
large SAN fabrics. DHCHAP provide authentication between C-series switches and other devices.
Port security
C-series port security features prevent unauthorized access to a switch port by:
•
Rejecting login requests from unauthorized Fibre Channel devices or switches
•
Reporting all intrusion attempts to the SAN administrator through system messages
•
Using the CFS infrastructure for configuration, distribution, and restricting it to CFS-enabled switches
Fabric binding
C-series switches in a fabric binding configuration ensure that ISLs are enabled between authorized
switches only. This feature prevents unauthorized switches from disrupting traffic or joining the fabric. The
EFMD protocol compares the list of authorized switches on each switch in the fabric.
C-series IP SAN security
This section describes the C-series IP SAN security features.
IPsec
C-series IPsec features ensure secure transmissions at the network layer. IPsec protects and
authenticates IP packets between participating devices (peers) over unprotected networks. IPsec
provides the following security services:
•
Data confidentiality
—Packets are encrypted by the sending device before transmitting them over the network.
•
Data integrity
—Packets are authenticated by the receiving device to ensure that data has not been altered during
transmission.
•
Data-origin authentication
—The packet source can be authenticated by the receiving device.
•
Anti-replay protection
—Replayed packets can be detected and rejected by the IPsec receiver.
408
C-series IP SAN security
CHAP authentication
C-series IP modules support CHAP, which uses a three-way handshake to ensure that validity of remote
clients. C-series CHAP requires that you configure a password. which the switch presents to the iSCSI
initiator. This password is used to calculate a CHAP response to a CHAP challenge sent to the IP port by
the initiator.
B-series Encryption Switch and Encryption FC Blade security
This section describes the security features for the B-series Encryption Switch and Encryption FC Blade.
For switch models and fabric rules, see B-series switches and fabric rules on page 105.
The B-series Encryption Switch is a high-performance, 32-port autosensing 8 Gb/s Fibre Channel switch
with data encryption/decryption and data compression capabilities. The switch is a network-based
solution that secures data-at-rest for tape and disk array LUNs using IEEE standard AES 256-bit
algorithms. Encryption and decryption engines provide in-line encryption services with up to 96 Gb/s
throughput for disk I/O (mix of ciphertext and cleartext traffic).
For more information about the B-series Encryption Switch, including deployment scenarios, see the
Fabric OS Encryption Administrator's Guide.
Features
•
High-performance, scalable fabric-based encryption to enforce data confidentiality and privacy
requirements
•
Unparalleled encryption processing at up to 96 Gb/s to support heterogeneous enterprise data centers
•
Integration with HPE Secure Key Manager, providing secure and automated key sharing between
multiple sites to ensure transparent access to encrypted data
•
Industry-standard AES 256-bit encryption algorithms for disk arrays on a single security platform for
SAN environments
•
Frame Redirection technology that enables easy, nonintrusive deployment of fabric-based security
services
•
Plug-in encryption services available to all heterogeneous servers, including virtual machines, in data
center fabrics
•
Scalable performance with on-demand encryption processing power to meet regulatory mandates for
protecting data
Hardware requirements
You can use either the Encryption SAN Switch or the Encryption FC Blade for data encryption as part of
the B-series Encryption Switch security platform.
Supported security components
B-series Encryption Switch security platform supports the following software components:
•
Encryption
•
Frame filtering
•
Advanced Zoning
•
WebTools
•
Enhanced Group Management
The B-series Encryption Switch security platform supports the following optional software components:
B-series Encryption Switch and Encryption FC Blade security
409
•
Encryption SAN Switch Power Pack+ Software Bundle (optional)
•
Adaptive Networking
•
Fabric Watch
•
Advanced Performance Monitor
•
Extended Fabrics
•
ISL Trunking
•
Integrated Routing
•
Data Center Fabric Manager Enterprise
B-series Fabric OS security
This section describes the B-series Fabric OS security features for resource protection, data protection,
and security validation.
Resource protection
This section describes the B-series Fabric OS resource protection features.
User management
Fabric OS provides two options for authenticating users:
•
Remote RADIUS services
—Users are managed by a remote RADIUS server. All switches in the fabric can be configured to
authenticate against this centralized database.
•
Local user database
—Users are managed by a local database, which is synchronized manually using the
distribute
command. This command pushes a copy of the switch's database to all other Fabric OS 5.3.0 (or
later) switches in the fabric.
Fabric OS uses RBAC to determine which commands are supported for each user.
Secure Shell
Fabric OS supports SSH encrypted sessions to ensure security. SSH encrypts all messages, including
client transmission of passwords during login. SSH includes a daemon (sshd), which runs on the switch
and supports many encryption algorithms, such as Blowfish-CBC and AES.
Commands that require a secure login channel must be issued from an original SSH session. Nested
SSH sessions will reject commands that require a secure channel.
NOTE:
Fabric OS 4.1.0 (or later) supports SSH V2.0 (ssh2).
To ensure a secure network, avoid using Telnet or any other unprotected applications to communicate
with switches.
Hypertext Transfer Protocol over SSL
B-series WebTools support the use of HTTPS.
410
B-series Fabric OS security
The SSL protocol provides secure access to a fabric through web-based management tools like B-series
WebTools. Switches configured for SSL grant access to the management tools through HTTPS links. SSL
uses PKI encryption to protect data. PKI is based on digital certificates obtained from an Internet CA,
which acts as the trusted agent. These certificates are based on the switch IP address or fully qualified
domain names.
NOTE:
If you change the switch IP address or domain name after activating its digital certificate, you may need to
obtain and install a new certificate.
Browser and Java support
Fabric OS 4.4.0 (or later) supports the following browsers for SSL connections:
•
Internet Explorer (Microsoft Windows)
•
Mozilla (Oracle Solaris and Red Hat Linux)
NOTE:
In countries that allow the use of 128-bit encryption, use the current version of the browser.
Upgrade to the Java 1.5.0_06 plug-in on the management station.
SNMP
B-series switches have an SNMP agent and MIB, which allow the administrator to program tools to set up
switch variables and enterprise-level management processes. The SNMP ACL allows the administrator to
restrict SNMP get and set operations to particular hosts and IP addresses, which provides enhanced
security for the SAN.
NOTE:
B-series switches support SNMP v3 and SNMP v1.
Secure Copy
SCP uses SSH to securely transfer files between systems. The administrator can set the Fabric OS
configure command to use SCP for uploads and downloads.
NOTE:
FTP is not a secure protocol. File contents are in clear text during transfer, including remote login
information. This limitation affects the following commands: saveCore, configUpload,
configDownload, and firmwareDownload.
IPFilter policy
The B-series IPFilter policy applies a set of rules to IP management interfaces as a packet filtering
firewall. The firewall permits or denies traffic through the IP management interfaces according to policy
rules.
Consider the following when setting IPFilter policies:
•
Fabric OS supports multiple IPFilter policies, which can be defined at the same time. Each policy is
identified by name and has an associated IPFilter type (IPv4 or IPv6). Do not mix IPFilter and IP
address types. You can have up to six IPFilter policies defined, but only one IPFilter policy for each
IPFilter type can be activated on the management IP interface.
•
Audit messages are generated for changes to the IPFilter policies.
Storage security
411
•
The IPFilter policy rules are examined one by one in a list until the end of the list is reached.
•
To ensure optimal performance, the most important rules should be listed first.
Data protection
This section describes features for data protection with B-series Fabric OS.
Fibre Channel ACLs
B-series Fabric OS uses ACLs to restrict access to data resources based on defined policies.
Fabric OS provides the following policies:
•
FCS policy
—Determines which switches can change fabric configurations
•
DCC policies
—Determines which Fibre Channel device ports can connect to which switch ports
•
SCC policy
—Determines which switches can join with another switch
•
IPFilter policy
—Filters traffic based on IP addresses
Each supported policy is identified by name; only one policy of each type can exist (except for DCC
policies).
Table 180: Methods for identifying policy numbers
Policy
Device port
WWN
Switch port WWN
Domain ID
Switch name
FCS_POLICY
No
Yes
Yes
Yes
DCC_POLICY_nn
n
Yes
Yes
Yes
Yes
SCC_POLICY
No
Yes
Yes
Yes
Authentication policy
By default, Fabric OS uses DHCHAP or FCAP for switch authentication. These protocols use shared
secrets and digital certificates, based on switch WWN and PKI technology. Authentication automatically
defaults to FCAP if both switches are configured for FCAP.
Consider the following when configuring authentication with Fabric OS:
412
•
Fabric OS 5.3.0 (or later) is required for DHCHAP.
•
DHCHAP requires the definition of a pair of shared secrets, known as a secret key pair. Each switch
can share a secret key pair with any other switch or host in the fabric.
•
PKI certificates must be installed on both switches to use FCAP.
Data protection
•
DHCHAP and FCAP are not compatible with SLAP, which is the only protocol supported in Fabric OS
3.1 and 4.2.
•
Fabric OS 5.3.0 switch-to-switch authentication is backward compatible with 3.2, 4.2, 4.4, 5.0, 5.1, and
5.2.
•
In the default configuration, FCAP authentication is tried first, then DHCHAP authentication. Each
switch can be configured to negotiate one or both types.
•
The Authentication policy is designed to accommodate mixed fabric environments that include
switches running Fabric OS 5.3.0 (and earlier).
•
When the Authorization policy is activated, you cannot implement a B-series Secure Fabric OS
environment.
E_Port Authentication
The E_Port Authentication policy allows you to configure DHCHAP authentication on the switch. By
default, the policy is set to PASSIVE.
Device Authentication policy
The Device Authentication policy is specific to HBAs. Fabric-wide distribution of the Device Authentication
policy is not supported because:
•
You must set the HBA and switch shared secrets manually.
•
Most HBAs do not support the defined DH groups used in DHCHAP.
NOTE:
By default, the switches are set to OFF, causing the security bit to be cleared during fabric login.
Zones
For detailed information about B-series switch zoning, see Zoning guidelines for B-series Fibre
Channel switches on page 134.
B-series IPsec
B-series IPsec uses cryptographic security to ensure private, secure communications over IP networks.
Consider the following when using IPsec with B-series switches:
•
IPsec is disabled by default when creating FCIP tunnels.
•
IPsec provides greater security with tunneling on the B-series StoreFabric SN4000B SAN Extension
Switch, 1606 Extension SAN Switch, DC Dir Switch MP Extension Blade, or MP Router Blade. IPsec
does not require that you configure security for each application that uses TCP/IP. When configuring
IPsec, you must ensure that a compatible StoreFabric SN4000B SAN Extension Switch, 1606
Extension SAN Switch, DC Dir Switch MP Extension Blade, or MP Router Blade with the same version
of FOS is at each end of the FCIP tunnel.
For compatible B-Series FCIP gateways, see Table HPE FCIP gateways
•
IPsec supports FCIP tunnels with or without IP compression, FCIP fastwrite, or tape pipelining.
B-series iSCSI Blade
B-series iSCSI Blade supports CHAP authentication for iSCSI initiator authentication.
Storage security
413
Security validation
B-series Fabric OS supports a logging mechanism that captures and tracks events that are vital to
security validation.
Key management
StorageWorks Secure Key Manager for HPE LT04 tape libraries is part of the Secure Advantage solution.
Secure Key Manager features include:
•
•
•
Centralized encryption key management for LT04 tape libraries
◦
Automatic policy-based key generation and management supporting key and cartridge granularity
◦
ISV transparent key archival and retrieval for multiple libraries
◦
Extensible to emerging open standards
Strong auditable security for encryption keys to ensure compliance
◦
Hardened server appliance
◦
Secure identity-based access, administration, and logging
◦
Designed for FIPS 140-2 validation
Reliable lifetime key archival, which ensures key availability, even in the event of a site disaster
◦
Automatic multiple-site clustering, key encryption, and failover
◦
Comprehensive backup and restore functions for keys
◦
Redundant device components and active alerts
Secure Key Manager validation process
The HPE CLW enhances the Secure Key Manager validation process.
The CLW features include:
•
High-performance appliance with the following modules: Log Manager, Analysis Manager, and Realtime Alert Manager
•
High-speed collection and analysis of log data, which automates compliance reporting for industry and
government standards
Integration of key management with partners
Secure Key Manager can be integrated with third-party and partner products (such as the C-series SME)
to provide a standard enterprise data security solution.
414
Security validation
Best practices
This chapter describes HPE best practices for SAN design and implementation. It describes the following
topics:
•
SAN planning on page 415
•
Design specification on page 416
•
SAN topology on page 416
•
SAN configuration on page 418
•
Storage-based LUN masking on page 419
•
Zoning on page 419
•
FCoE switch configuration quick-setup instructions on page 423
•
SAN scaling on page 435
•
SAN fabric merging on page 436
For SAN design assistance, see the Storage Services website http://www.hpe.com/support/
HPEservices.
SAN planning
Allocate adequate time to plan your SAN prior to implementation. Design a SAN that fulfills current and
future requirements for capacity and connectivity.
During the planning phase, consider these design factors and recommendations:
•
Deployment strategy
Consider initially implementing entry-level SANs that can be interconnected to increase capacity.
Entry-level SANs are relatively easy to implement. Enterprise SANs offer economy of scale; however,
they are more complex and can take longer to implement.
•
Topology design
Choose an initial design that can accommodate expansion without transitioning to a different topology.
•
Experience level
If you have limited experience implementing a SAN, start with an entry-level SAN. As you gain
experience, deploy mid-range or enterprise-level SANs.
•
SAN management strategy
Specify the policies, identification schemes, and tools to manage your SAN.
•
Technological advances
Anticipate the gradual availability of Fibre Channel switches that have more ports and faster
interconnect speeds.
Best practices
415
Design specification
During the planning process, create a specification that describes your decisions and design. Review and
evaluate the design, compare alternatives, make adjustments, and communicate plans before
implementation.
A complete design specification includes the following elements:
•
Topology map
—Shows the logical SAN topology and fabric interconnect scheme; describes a strategy to
accommodate expansion and technological advances
•
Configuration layout
—Shows the physical layout of components; use for troubleshooting and to verify the correct
connectivity
•
Storage map
—Defines the storage system configuration and settings, such as host LUN allocation and RAID levels
•
Zoning map
—Defines the communication access settings for devices and user ports in the SAN
SAN topology
This section describes SAN features for enterprise-level SANs:
•
Multi-fabric SANs on page 416
•
Failover protection on page 417
•
Data access patterns on page 417
•
ISL ratio on page 417
•
Incremental SAN expansion on page 417
Multi-fabric SANs
Hewlett Packard Enterprise recommends using two or more separate fabrics for enterprise-level SANs.
Multiple fabrics protect against potential failure points, such as hardware, software, or operator error. The
failure of one fabric does not affect other fabrics in the SAN.
SAN and fabric monitoring
For all single and multiple fabric configurations, Hewlett Packard Enterprise recommends that you utilize
intelligent fabric monitoring tools such as HPE Intelligent Infrastructure Analyzer Software (IIAS),SAN
infrastructure monitoring on page 438, B-series Fabric Watch and C-series RMON (see the user
documentation for your switch). These products provide detailed monitoring of individual Fibre Channel
ports, notifications, and in some cases, automated isolation of inoperative devices. This can help you to
identify abnormal conditions and avoid operational degradation. This degradation can adversely affect
operation, but does not necessarily result in a failover event.
416
Design specification
NOTE:
These tools are effective in detecting and avoiding most abnormal conditions. Failing or marginal
hardware can cause rare conditions which are not detected. In order to minimize these rare conditions,
Hewlett Packard Enterprise recommends that you implement proper cable management practices and
end-to-end SAN monitoring.
Failover protection
Use failover technology in SAN configurations that have two or more fabrics. Each server has two or more
HBAs. If the communication path from one HBA to the storage system fails, the I/O traffic is rerouted
through the other HBA.
To minimize the risk of uneven workloads, configure the separate fabrics for similar size and topology.
You can also use failover protection in SANs with only one fabric to protect against HBA, path, and
storage controller failures. For more information, see Data availability on page 40.
Data access patterns
Review your data access needs before making a topology choice. The optimum SAN configuration
depends on I/O traffic requirements and data access patterns:
•
Local (one-to-one)
—Data access between a local server and a storage system connected to the same switch
•
Centralized (many-to-one)
—Data access between multiple, dispersed servers and one centrally located storage system
•
Distributed (many-to-many)
—Data access between multiple, dispersed servers and storage systems
For recommended topologies based in the primary data access type, see Table Data access performance
by SAN fabric topology.
ISL ratio
Determine the ISL ratio for switch-to-switch connectivity based on the workload of servers and storage
systems. In some cases, you can assess the I/O requirements of your applications and servers by using
application sizing tools. After deployment, use current system measurements to determine the actual
workload, and modify your implementation if the initial design does not meet your requirements. For more
information, see Core-edge fabric types on page 32.
Incremental SAN expansion
Plan for expansion when the initial design is a subset of a future, larger design. For example, if you are
using a core-edge topology in the initial design, allocate spare ports on the core switches to support
addition of edge switches.
To expand the SAN, you can make incremental changes rather than reconfiguring the entire SAN.
Changes to the core switches are isolated from the edge switches, which minimizes the effect of changes
required to support core growth. Changes to the server connection to an edge switch are isolated from
the core, which minimizes the effect of server-related changes. If you are using two or more fabrics, you
can temporarily route server I/O traffic to one fabric while the other fabric is being modified.
Failover protection
417
SAN configuration
After completing the planning phase, you can configure your SAN. During the configuration phase, record
details about the physical configuration.
To facilitate maintenance, observe the following practices:
•
Record keeping
Record the cable connections on the configuration layout diagram. Record the WWN and location of
each node and device.
•
HBA labels
Affix a label on each HBA that clearly identifies the WWN. HPE storage systems are prelabeled with
this information. Affix another label in plain view if necessary.
•
Cable labels
Label both ends of each cable with a cable number or color-coding scheme. This allows you to quickly
identify each cable. Securely affix a label to each end of the cable to identify connection points, such
as TO and FROM.
•
Switch ports
Use port plugs to protect unused switch ports; never leave ports exposed.
•
Cable dressing
Use care when routing fiber optic cable and ensure that cables conform to the minimum bend radius
requirements, see Table Rules for fiber optic cable connections. Use hook-and-loop (such as Velcro
brand) tie wraps to group and support the cables.
CAUTION:
Plastic tie wraps can damage the internal fiber core if over-tightened.
•
Cable symmetry
When connecting cables, use similar slot and port numbers. For example, connect HBA 1 to SAN
fabric 1, HBA 2 to SAN fabric 2, and so on.
Consider the following when configuring your SAN:
•
Fibre Channel switch configuration on page 418
•
Server setup on page 418
•
Storage system configuration on page 419
Fibre Channel switch configuration
Fibre Channel switches are preconfigured with compatible parameter settings. You must configure each
switch with a unique domain ID.
Server setup
When setting up servers:
418
SAN configuration
•
For each platform or operating system type, use only HPE-supported drivers and configuration
settings.
•
Ensure that the servers have the supported operating system versions and all required updates.
•
Use an alphanumeric naming scheme for multiple servers of the same type, such as WIN01 and
WIN02 for Windows servers.
Storage system configuration
When configuring storage systems:
•
Use the storage map created in the planning phase to configure each storage system.
•
Verify server-to-storage connectivity, and access one server at a time.
•
When defining storagesets, disable all access first, and then enable the desired access.
•
Define storage system connection names that are consistent with zoning alias names. Use consistent
names for storage port and controller connections. Use a naming scheme that represents the physical
connectivity.
Storage-based LUN masking
Use storage-based LUN masking to allow or prevent access to storage system LUNs from one or more
servers.
•
For EVA storage systems, use SSP.
•
For HPE XP storage systems, use LUN Configuration and Security Manager XP.
During SCSI initialization, the server queries the storage port for a list of available LUNs and their
properties. The storage system compares the WWN of the requesting HBA to the defined zone list and
returns the LUNs assigned to the WWN. Any other LUNs on that storage port are not available to the
server.
Zoning
This section describes configuration recommendations for:
•
Zoning enforcement on page 419
•
Zoning guidelines on page 420
•
EBS zoning on page 422
•
Zone naming on page 422
Zoning enforcement
To protect against unauthorized access, Fibre Channel switches provide three types of zoning
enforcement (listed here in order of enforcement):
•
Access authorization
Access authorization provides frame-level access control in hardware and verifies the SID-DID
combination of each frame. The frame is delivered to the destination only if specified as a valid
Storage system configuration
419
combination in the zone definition. This method offers a high level of security and is classified as hard
zoning because it requires hardware resources at the ASIC level.
•
Discovery authentication
Discovery authentication occurs during access to the NS directory. The fabric presents only a partial
list of authorized devices from the NS directory. This method may be enforced by software or
hardware, depending on the switch model. When enforced by software, this method is susceptible to
security threats from unauthorized devices that violate Fibre Channel protocols.
•
Soft-plus zoning by login authentication
In addition to discovery authentication, some switches enforce authentication at the Fibre Channel
protocol login frame level. For example, if a host sends a PLOGI frame to a device that is not a
member of its zone, the frame is dropped. Login authentication provides more protection than
discovery authentication but is not as secure as access authorization.
The zone configuration and the switch model determine the type of zoning enforcement you can
implement in your SAN fabric. For information about the relationship of zone configuration with zoning
enforcement, see the following tables:
•
Zoning enforcement for B-series Fibre Channel switches and MP Router LSANs (B-series)
•
Zoning enforcement for C-series Fibre Channel switches (C-series)
•
Zoning enforcement for H-series switches (H-series)
Some system restrictions affect the movement of devices within the fabric, regardless of zoning type. For
example, some operating systems, such as HP-UX, create device file names based on the 24-bit fabric
address and do not allow moving the device to a different port. A change in the address causes the
device to be treated as a different device.
Zoning guidelines
Use one of the following zoning methods:
•
Operating system (minimum level required)
•
HBA
•
HBA port
•
NPIV port
•
3PAR persistent ports
•
Application
•
Port allocation
Zoning by operating system
Zoning by operating system is the minimal required zoning method. This method allows multiple HBAs
with the same operating system to be grouped with the accessed storage ports. Zoning by operating
system prevents the interaction of HBAs with incompatible operating systems.
This method limits the number of zones in a fabric. A large zone can be divided into multiple zones within
the operating system type. Zoning by operating system type limits disruptions and the number of fabric
change notifications.
Certain situations require zoning by HBA, for example, configuring server access to multiple storage
types. For additional zoning requirements, see:
420
Zoning guidelines
•
Zoning limits and enforcement on page 133
(B-series)
•
Zoning limits and enforcement on page 153
(C-series)
•
Zoning limits and enforcement on page 166
(H-series)
•
Common server access, different storage system types on page 233
Zoning by HBA
For zoning by HBA, each zone has only one HBA (initiator); each of the target devices is added to the
zone. Typically, a zone is created for the HBA and the disk storage ports are added. If the HBA also
accesses tape devices, Hewlett Packard Enterprise recommends that a second zone be created for the
HBA and associated tape devices. For zoning requirements with different HBA models on the same
server, see Common server, different HBAs on page 233.
This zoning philosophy is the preferred method for both standalone and clustered systems; zoning by
single HBA requires the creation of numerous zones; each containing only a few members. Zone
changes affect a small number of devices, minimizing the effect of an incorrect zone change.
Zoning by HBA port
Zoning by HBA port applies when you are utilizing dual-ported HBAs. From a zoning perspective, you can
view each port as if it were a separate HBA. As such, you would use the same criteria as described
above in the Zoning by HBA section. In this case however, each HBA port should be thought of as a
separate HBA.
Zoning by NPIV port
With NPIV, one physical link is shared by multiple virtual ports and each is assigned a different WWPN.
Similar to zoning by HBA port, from a zoning perspective, each virtual port should be viewed as if it were
a separate HBA.
Zoning with 3PAR persistent ports
3PAR Persistent Ports technology allows for a completely non-disruptive software upgrade environment
(from the host pathing point of view) where host-based multipathing software will not be involved in the
software upgrade process. Additionally, 3PAR Persistent Ports technology renders an array node failure
transparent to hosts using the array, avoiding the need for the multipathing software of the host to
maintain host connectivity for node failure recovery. For information about zoning when using this feature,
see the HPE 3PAR Persistent Ports technical whitepaper (4AA4-4545ENW), available on the Hewlett
Packard Enterprise storage website: http://www.hpe.com/info/StoreFabric. The whitepaper has a
separate section on "Best practice and zoning and multipathing considerations".
Zoning by application
Zoning by application configures multiple, sometimes incompatible, operating systems into the same
zones. This method allows the potential for disruptions among servers, such as a web server disrupting a
data warehouse server. A zone with a large number of members is susceptible to more administrative
errors, such as distribution of RSCNs to a larger group than necessary.
Zoning by HBA
421
Zoning by port allocation
Avoid zoning by port allocation unless you have strictly enforced processes for port and device allocation
in the fabric.
There is no consequence for the change of WWN when a storage port, server HBA, or tape drive is
replaced. If the new device connects to the original port, it continues to have the same access rights. You
can preassociate switch ports with storage ports, and therefore control the server-to-storage ratio. This
technique prevents overloading of a storage port by allowing you to limit the number of servers that are
allowed access.
EBS zoning
For EBS zoning recommendations, see the HP Enterprise Backup Solution Design Guide, available at
http://www.hpe.com/info/ebs.
Zone naming
When naming zones:
•
Configure and test small zones that are a subset of the larger SAN.
•
Use meaningful names for zones and zone member aliases.
•
Use a consistent naming scheme for all components.
•
Before making zoning changes, save the current configuration.
•
If possible, do not make zoning changes when a switch in the fabric is temporarily unavailable.
Naming by identifier type
Define zone member names by using one of the following naming conventions:
•
Domain ID and port number
Use the switch domain ID and port number to identify zone members. The zone definition remains
intact when an HBA or controller is replaced by another with a different WWN. However, when a
device is moved to a different port in the fabric, it is no longer a member of the zone.
•
WWN
Use the device WWN to uniquely identify zone members. The zone definition remains intact when the
device is moved to a different port or switch in the fabric. However, if an HBA is replaced by another
with a different WWN, you must update the zone definition.
•
WWN with domain ID and port number
Use the switch domain ID, port number, and WWN to identify zone members.
Case sensitivity of fabric identifiers
To define an alias naming scheme, consider the case sensitivity of fabric identifiers:
•
Case sensitive
—Switch alias names
•
Not case sensitive
—Device connection names
422
Zoning by port allocation
Case sensitivity example
RING_1 and Ring_1 are distinct switch identifiers.
Server naming
Servers are identified by the WWN of the HBA. For server aliases, use the operating system name and
the HBA number. For example, for server WIN01 with one HBA, define the alias as WIN01_HBA01; for
the second HBA, define the alias as WIN01_HBA02.
Storage system naming
Fibre Channel storage systems have a unique WWN for each controller port. When implementing multiple
fabrics, different ports are configured in each fabric.
Observe the following best practices:
•
Assign a unique number to each storage port.
For example, ports in fabric 1 have aliases S1_A1 and S1_A2.
•
Use a consistent alias naming convention for ports and HBAs throughout the configuration.
For example, configure HBA 1, S1_A1 and S1_B2 in fabric 1; configure HBA 2, S1_A2 and S1_B1 in
fabric 2.
•
Define host connection names for the HBA WWNs similar to the alias names in the fabric.
For example, define alias WIN01_HBA1 for Windows server 1 and HBA 1.
Alias convention example
A storage system connected to two fabrics has the following aliases:
•
•
First fabric:
◦
S1_A1
◦
S1_B2
Second fabric:
◦
S1_A2
◦
S1_B1
Ports A1 and B2 are cabled to the first fabric. Ports A2 and B1 are cabled to the second fabric.
FCoE switch configuration quick-setup instructions
FCoE CN switches have dual capabilities in that they serve as both an Ethernet switch and an FC switch.
You must perform a setup procedure to achieve the desired function.
Server naming
423
IMPORTANT:
The procedures in this section are intended as a quick-start guide to configuring the FCoE ports on
an FCoE CN switch to access the FC ports on the FCoE CN switch and other attached FC switches.
It is intended for users who are familiar with FCoE switches and their associated configuration
commands.
HPE 5820 FCoE Converged Network Switch quick setup
This procedure is intended for users who are familiar with HPE A-series switches. Use this procedure to
enable servers with CNAs attached to the HPE 5820 FCoE Converged Network Switch to access devices
from an attached B-series, C-series, or H-series FC fabric.
IMPORTANT:
If you are not familiar with A-series switches, refer to the 5820 product documentation for detailed
instructions on setting up the switch.
Procedure
1. Create 3 VLANs (for LAN, SAN, and SAN discovery traffic).
<switchname> system-view
[switchname] vlan 1001
[switchname-vlan1001] description ToLAN
[switchname-vlan1001] quit
[switchname] vlan 4001
[switchname-vlan4001] description ToSAN
[switchname-vlan4001] quit
[switchname] vlan 3001
[switchname-vlan3001] description FIPVLAN
[switchname-vlan3001] protocol-vlan 0 mode ethernetii etype 8914
[switchname-vlan3001] quit
[switchname]
2. Configure DCBX.
[switchname] acl number 4000 name DCBX
[switchname-acl-ethernetframe-4000-DCBX] rule 0 permit type 8906 ffff
[switchname-acl-ethernetframe-4000-DCBX] rule 5 permit type 8914 ffff
[switchname-acl-ethernetframe-4000-DCBX] quit
[switchname] traffic classifier DCBX operator or
[switchname-classifier-DCBX] if-match acl 4000
[switchname-classifier-DCBX] quit
[switchname] traffic behavior DCBX
[switchname-behavior-DCBX] remark dot1p 3
[switchname-behavior-DCBX] quit
[switchname] qos policy DCBX
[switchname-qospolicy-DCBX] classifier DCBX behavior DCBX mode dcbx
[switchname-qospolicy-DCBX] quit
3. Configure ETS.
[switchname] qos map-table dot1p-lp
[switchname-maptbl-dot1p-lp] import
[switchname-maptbl-dot1p-lp] import
[switchname-maptbl-dot1p-lp] import
[switchname-maptbl-dot1p-lp] import
424
0
1
2
3
export
export
export
export
HPE 5820 FCoE Converged Network Switch quick setup
0
0
0
1
[switchname-maptbl-dot1p-lp]
[switchname-maptbl-dot1p-lp]
[switchname-maptbl-dot1p-lp]
[switchname-maptbl-dot1p-lp]
[switchname-maptbl-dot1p-lp]
import
import
import
import
quit
4
5
6
7
export
export
export
export
0
0
0
0
4. Configure Interfaces (3 types).
a. Server CNA Interfaces
[switchname] interface Ten-GigabitEthernet1/0/1
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
[switchname-interface Ten-GigabitEthernet1/0/1]
port link-type hybrid
port hybrid vlan 4001 tagged
port hybrid vlan 1001 3001 untagged
port hybrid pvid vlan 1001
undo port hybrid vlan 1
port hybrid protocol-vlan vlan 3001 0
qos apply policy DCBX outbound
lldp tlv-enable dot1-tlv dcbx
priority-flow-control auto
priority-flow-control no-drop dot1p 3
qos trust dot1p
qos wrr 7 group sp
qos wrr 6 group sp
qos wrr 5 group sp
qos wrr 4 group sp
qos wrr 3 group sp
qos wrr 2 group sp
qos wrr 1 group byte-count 15
qos wrr 0 group byte-count 15
broadcast-suppression 1
multicast-suppression 1
unicast-suppression 1
quit
b. Network (No SAN Access) Interfaces
[switchname] interface Ten-GigabitEthernet1/0/14
[switchname-interface Ten-GigabitEthernet1/0/14]
[switchname-interface Ten-GigabitEthernet1/0/14]
[switchname-interface Ten-GigabitEthernet1/0/14]
[switchname-interface Ten-GigabitEthernet1/0/14]
[switchname-interface Ten-GigabitEthernet1/0/14]
port
port
port
undo
quit
link-type trunk
trunk permit vlan 1001
trunk pvid vlan 1001
port trunk permit vlan 1
c. Internal 5820X FCoE module Interfaces (1/1/1-1/1/4 and/or 1/2/1-1/2/4)
[switchname] interface Ten-GigabitEthernet1/1/1
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
[switchname-interface Ten-GigabitEthernet1/1/1]
port link-type hybrid
port hybrid vlan 4001 tagged
port hybrid vlan 3001 untagged
port hybrid pvid vlan 3001
undo port hybrid vlan 1
stp disable
lldp tlv-enable dot1-tlv dcbx
priority-flow-control auto
priority-flow-control no-drop dot1p 3
qos trust dot1p
quit
Best practices
425
5. Save changes and exit system-view.
[switchname]save
[switchname]quit
<switchname>
6. Configure 5820 FCoE module.
a. Connect to FCoE module from 5820 CLI.
<switchname>oap connect slot 1 system subslot1
At the Login prompt, type the initial default user account, admin. At the Password prompt, type the
initial default password, password.
H3C #>admin start
H3C (admin) #>config edit
b. Create VLAN to match 5820 ToSAN VLAN.
H3C (admin-config) #> vlan 4001 create
H3C (admin-config) #> vlan 4001 add port 4-7
c. Add ToSAN VLAN to default FCF.
H3C (admin-config) #> fcf list
Verify default FCF and VLAN are FCF: 0EFC00 VLAN: 1002.
H3C (admin-config) #> fcf 0EFC00 remove vlan 1002
H3C (admin-config) #> fcf 0EFC00 add vlan 4001
d. Save and activate changes.
H3C (admin-config) #>config save
H3C (admin) #>config activate
H3C (admin) #>admin stop
e. Optionally configure FCoE module IP address for management access.
H3C #> admin start
H3C #>set setup system
(and follow prompts)
f. Return back to 5820 prompt.
H3C #> quit
Press CTRL+K to return to 5820 prompt.
<switchname>
2408 FCoE Converged Network Switch and DC SAN Director Switch 10/24
FCoE Blade quick setup
This procedure is intended for users who are familiar with Brocade FC switches and have experience
merging B-series FC switches into an existing FC fabric. Use this procedure to enable servers with CNAs
attached to the 2408 FCoE Converged Network Switch or the DC SAN Director Switch 10/24 FCoE Blade
to access devices on the attached B-series FC fabric.
426 2408 FCoE Converged Network Switch and DC SAN Director Switch
10/24 FCoE Blade quick setup
IMPORTANT:
If you are not familiar with Brocade FC switches or you do not have experience merging B-series FC
switches into an existing FC fabric, use the detailed instructions found in the switch user guide to
set up your switch.
Procedure
1.
Configure LLDP for FCoE (common to all CEE ports).
switch:admin> cmsh
switch# enable
switch# config terminal
switch(config)# protocol lldp
switch(conf-lldp)# advertise dcbx-fcoe-app-tlv
switch(conf-lldp)# advertise dcbx-fcoe-logical-link-tlv
switch(conf-lldp)# exit
2.
Create a CEE map to carry LAN traffic (60%) and SAN traffic (40%) (common to all CEE ports).
switch(config)# cee-map default
switch(conf-ceemap)# priority-group-table 1 weight 40 pfc
switch(conf-ceemap)# priority-group-table 2 weight 60
switch(conf-ceemap)# priority-table 2 2 2 1 2 2 2 2
switch(conf-ceemap)# exit
3.
Create an FCoE VLAN for traffic to and from the FC fabric (required for FCoE).
switch(config)#
switch(config)#
switch(config)#
switch(config)#
switch(config)#
vlan classifier rule 1 proto fcoe encap ethv2
vlan classifier rule 2 proto fip encap ethv2
vlan classifier group 1 add rule 1
vlan classifier group 1 add rule 2
interface vlan 5
(Can be any VLAN number other than 1)
switch(conf-if-vl-5)# fcf forward
switch(conf-if-vl-5)# exit
4.
Configure interfaces (required for each port being configured).
switch(config)# interface tengigabitethernet 0/0
Change Port ID
switch(config-if-te-0/0)# switchport
switch(config-if-te-0/0)# switchport mode converged1
switch(config-if-te-0/0)# switchport converged allowed vlan add 51
VLAN)
switch(config-if-te-0/0)# vlan classifier activate group 1 vlan 51
switch(config-if-te-0/0)# cee default1
switch(config-if-te-0/0)# exit
FCoE Required (Step 3
1This
5.
command allows the port to access the FCoE VLAN. You can omit this command for non-FCoE
ports; however, both FCoE and non-FCoE ports might require a similar command for access to other
VLANs.
6.
Repeat 4 on page 427 for each interface you are configuring.
Best practices
427
7.
Perform a port shutdown/no shutdown operation (required for each port for the configuration change
to be enabled).
switch(config)# interface tengigabitethernet 0/0
Change Port ID
switch(config-if-te-0/0)# shutdown
switch(config-if-te-0/0)# no shutdown
switch(config-if-te-0/0)# exit
8.
Repeat 7 on page 428 for each interface you are configuring.
9.
Save the running configuration to boot flash.
switch(config)# exit
switch# copy running-config startup-config
Overwrite the startup config file (y/n): y
Building configuration...
switch#
10. Verify that the CEE port link status and VLAN status are correct.
switch# show ip interface brief
Interface
IP-Address
Protocol
=========
==========
========
TenGigabitEthernet 0/0
unassigned
Status
======
up
up
switch#show vlan brief
VLAN
Name
State
Ports
(u)-Untagged, (t)-Tagged
======= ================ ======= ===============================
1
default
ACTIVE Te 0/0(u)…
5
VLAN0005
ACTIVE Te 0/0(u)…
switch# exit
switch:admin>
11. Verify the status of the FC and FCoE virtual FC ports.
BR8000-01:admin> switchshow
switchName:
BR8000-1
switchType:
76.7
switchState:
Online
switchMode:
Native
switchRole:
Subordinate
switchDomain:
4
switchId:
fffc04
switchWwn:
10:00:00:05:1e:76:77:80
zoning:
ON (Brocade_East)
switchBeacon:
OFF
FC Router:
OFF
FC Router BB Fabric ID: 1
Index Port Address Media Speed State
Proto
==============================================
0
0
040000
id
N4
Online
FC E-Port
1
1
040100
id
N4
Online
FC E-Port
2
2
040200
id
N4
Online
FC E-Port
3
3
040300
id
N4
Online
FC E-Port
(upstream)
4
4
040400
id
N8
No_Light
FC
428
Best practices
10:00:00:05:1e:36:2a:70
10:00:00:05:1e:36:2a:70
10:00:00:05:1e:36:2a:70
10:00:00:05:1e:36:2a:70
"BR48-02"
"BR48-02"
"BR48-02"
"BR48-02"
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
040500
040600
040700
040800
040900
040a00
040b00
040c00
040d00
040e00
040f00
041000
041100
041200
041300
041400
041500
041600
041700
041800
041900
041a00
041b00
041c00
041d00
041e00
041f00
id
id
id
-------------------------
N8
N8
N8
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
10G
No_Light
No_Light
No_Light
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
Online
FC
FC
FC
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
FCoE
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
VF-Port
1
1
0
1
1
1
1
1
1
0
0
0
1
1
0
0
0
0
0
0
0
0
0
0
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
VN-Port(s)
NOTE:
Ports 8 through 31 are the virtual FC ports. To display the FCoE virtual FC devices connected to
those ports, enter the following command.
BR8000-01:admin> fcoe --loginshow
==============================================================================
==
Port
Te port
Device WWN
Device MAC
Session MAC
==============================================================================
==
8
Te 0/0
10:00:00:00:c9:93:c9:13 00:00:c9:93:c9:13 0e:fc:00:04:08:01
9
Te 0/1
10:00:00:00:c9:93:c9:2b 00:00:c9:93:c9:2b 0e:fc:00:04:09:01
11
Te 0/3
10:00:00:00:c9:93:c8:b3 00:00:c9:93:c8:b3 0e:fc:00:04:0b:01
12
Te 0/4
10:00:00:00:c9:93:ca:8b 00:00:c9:93:ca:8b 0e:fc:00:04:0c:01
13
Te 0/5
10:00:00:00:c9:93:c9:bf 00:00:c9:93:c9:bf 0e:fc:00:04:0d:01
14
Te 0/6
10:00:00:00:c9:93:ca:e3 00:00:c9:93:ca:e3 0e:fc:00:04:0e:01
15
Te 0/7
10:00:00:00:c9:93:ca:eb 00:00:c9:93:ca:eb 0e:fc:00:04:0f:01
16
Te 0/8
10:00:00:00:c9:93:c9:1b 00:00:c9:93:c9:1b 0e:fc:00:04:10:01
20
Te 0/12
10:00:00:00:c9:93:ca:93 00:00:c9:93:ca:93 0e:fc:00:04:14:01
21
Te 0/13
10:00:00:00:c9:93:c8:43 00:00:c9:93:c8:43 0e:fc:00:04:15:01
BR8000-1:admin>
HPE C-series Nexus 5010/5020 Converged Network Switch and Cisco
5548UP/5596UP Converged Network Switch quick setup
This procedure is intended for users who are familiar with Cisco MDS FC switches and have experience
merging C-series MDS FC switches into an existing MDS FC fabric. Use this procedure to enable servers
with CNAs attached to the HPE C-series Nexus 5010/5020 Converged Network Switch and Cisco
5548UP/5596UP Converged Network Switch to access devices on the attached C-series FC fabric.
HPE C-series Nexus 5010/5020 Converged Network Switch and Cisco
5548UP/5596UP Converged Network Switch quick setup 429
IMPORTANT:
If you are not familiar with Cisco FC switches or you do not have experience merging C-series FC
switches into an existing FC fabric, use the detailed instructions found in the switch user guide to
set up your switch.
Table 181: Recommended VFC port assignments
Model
Slot
Number of FCoE ports
(maximum)
VFC port assignments
(recommended)
HPE Cseries
Nexus 5010
Converged
Network
Switch
1 (Standard)
20
VFC ports 1 through 20
2 (Optional expansion
module slot)
6
VFC ports 41 through 46
HPE Cseries
Nexus 5020
Converged
Network
Switch
1 (Standard)
40
VFC ports 1 through 40
2 (Optional expansion
module slot1)
6
VFC ports 41 through 46
3 (Optional expansion
module slot1)
6
VFC ports 47 through 52
32
VFC ports 1 through 32
16
VFC ports 33 through 48
48
VFC ports 1 through 48
16
VFC ports 49 through 64
16
VFC ports 65 through 80
16
VFC ports 81 through 96
Cisco Nexus 1 (Standard)
5548UP
Converged
2 (Optional expansion
Network
module slot1)
Switch
Cisco Nexus 1 (Standard)
5596UP
Converged
2 (Optional expansion
Network
module slots1)
Switch
3 (Optional expansion
module slots1)
4 (Optional expansion
module slots1)
1 Optional expansion module slots can contain either 10-GbE ports or FC ports.
In the following examples, FCoE is enabled on a C-series Nexus 5010 Converged Network Switch, VLAN
200 is created, and the Ethernet ports are bound to a virtual SAN (VSAN 2) from an 8-port FC expansion
module. The commands are the same for the C-series Nexus 5020 Switch and the Cisco Nexus 5548UP
and Nexus 5596UP Switches.
To establish CNA connectivity and enable login to the C-series Nexus 5000 Converged Network Switch,
configure the IEEE DCB ports as follows:
430
Best practices
Procedure
1.
Enable FCoE (disabled by default).
NOTE:
The C-series Nexus 5000 Converged Network Switch will require a reload (reboot).
Nexus5010# configure terminal
Nexus5010(config)# feature fcoe
Nexus5010(config)# feature npiv
Nexus5010(config)# 2009 Apr 1 12:05:06 Nexus5010 %$ VDC-1 %$ %PLATFORM-2FC_LICENSE_DESIRED: FCoE/FC feature will be enabled after the
configuration
is saved followed by a reboot
Nexus5010(config)# exit
Nexus5010# copy running-config startup-config
[########################################] 100%
Packaging and storing to flash: \
Packaging and storing to flash: |
Packaging and storing to flash: /
NOTE:
Depending on the NX-OS version, a reload may be required when enabling features. When you
execute the feature command, a message appears to indicate if a reload is required.
2.
Reload the system if you are directed to do so. Otherwise, proceed to 3 on page 431.
Nexus5010#
reload WARNING: This command will reboot the system Do you want to
continue? (y/n) [n]
y The system is going down for reboot NOW!
3.
Create a new VLAN for FCoE.
By default, all ports are in VLAN 1, however, you must use a different VLAN for FCoE. In the
following example, VLAN 200 is created with access to Ethernet ports 1/1 to 1/20, and VFC ports 1–
20 are also created.
NOTE:
In the last section of this example, 1/1-20 indicates that the commands that follow apply to multiple
ports (in this case, ports 1/1 through 1/20). All 20 ports are set for switchport mode trunk, and
switchport trunk allowed is set for VLANs 1 and 200.
Nexus5010# configure terminal
Nexus5010(config)# vlan 200
Nexus5010(config-vlan)# exit
Nexus5010(config)# exit
Nexus5010# show vlan brief
VLAN Name
Status
Ports
---- -------------------------------------------------------------1
default
active
Eth1/1, Eth1/2, Eth1/3,
Eth1/4, Eth1/5, Eth1/6,
Eth1/7, Eth1/8, Eth1/9,
Best practices
431
200
Eth1/10,
Eth1/13,
Eth1/16,
Eth1/19,
VLAN0200
Eth1/11, Eth1/12,
Eth1/14, Eth1/15,
Eth1/17, Eth1/18,
Eth1/20
active
Nexus5010# configure terminal
Nexus5010(config)# interface ethernet 1/1-20
Nexus5010(config-if-range)# switchport mode trunk
Nexus5010(config-if-range)# switchport trunk allowed vlan 1, 2001
Nexus5010(config-if-range)# interface vfc 1-20
Nexus5010(config-if-range)# exit
1This
command allows the port to access the FCoE VLAN (VLAN 200 in this example). For nonFCoE ports, you can omit the FCoE VLAN from this command; however, both FCoE and non-FCoE
ports might require access to other VLANs.
4.
Create a new VSAN that includes the FC and VFC ports.
By default, all ports are in VSAN 1. Hewlett Packard Enterprise recommends that you use a different
VSAN for SAN connectivity. In this example, VSAN 2 is created and includes FC ports 2/1 through
2/8 and VFC ports 1 through 20.
NOTE:
VFC ports must be FCoE ports. FC ports cannot be VFC ports.
Nexus5010# configure terminal
Nexus5010(config)# vsan database
Nexus5010(config-vsan-db)# vsan 2
Nexus5010(config-vsan-db)# vsan 2 interface fc2/1-8
Nexus5010(config-vsan-db)# vsan 2 interface vfc 1-20
Nexus5010(config-vsan-db)# exit
Nexus5010(config)# exit
Nexus5010# show vsan membership
vsan 1 interfaces:
vsan 2 interfaces:
fc2/1
fc2/2
fc2/3
vfc1
vfc2
vfc3
vfc9
vfc10
vfc11
vfc17
vfc18
vfc19
fc2/4
vfc4
vfc12
vfc20
fc2/5
vfc5
vfc13
fc2/6
vfc6
vfc14
vsan 4094(isolated_vsan) interfaces:
5.
Associate the VLAN with the VSAN.
In this example, VLAN 200 is associated with VSAN 2.
Nexus5010# configure terminal
Nexus5010(config)# vlan 200
Nexus5010(config-vlan)# fcoe vsan 2
Nexus5010(config-vlan)# exit
Nexus5010(config)# exit
Nexus5010# show vlan fcoe
VLAN
432
Best practices
VSAN
Status
fc2/7
vfc7
vfc15
fc2/8
vfc8
vfc16
-------200
6.
-------2
-------Operational
Bind each VFC port to a unique Ethernet port by issuing the following commands on each port:
interface vfc n
bind interface ethernet slot/port
exit
NOTE:
Depending on your switch, up to 52 VFC ports may be available.
In Example 1: Creating and binding consecutive VFC ports, VFC ports 1 through 8 are created and
are bound to Ethernet ports 1/1 through 1/8, respectively. Example 2: Creating and binding
nonconsecutive VFC ports shows a more complex configuration in which the VFC ports are not
sequential.
Example 1: Creating and binding consecutive VFC ports
Nexus5010# configure terminal
Nexus5010(config)# interface vfc 1
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 2
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 3
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 4
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 5
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 6
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 7
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 8
Nexus5010(config-if)# bind interface
Nexus5010(config-if)# exit
Nexus5010(config)# interface vfc 1-8
Nexus5010(config-if)# no shutdown
Nexus5010(config-if)# exit
ethernet 1/1
ethernet 1/2
ethernet 1/3
ethernet 1/4
ethernet 1/5
ethernet 1/6
ethernet 1/7
ethernet 1/8
IMPORTANT:
Example 2: Creating and binding nonconsecutive VFC ports is provided for reference only. It
shows an alternate method of performing this step.
Best practices
433
In Example 2: Creating and binding nonconsecutive VFC ports, VFC ports 1 through 6, 10, and 20
through 25 are created, and each VFC port is bound to an Ethernet port. Because the VFC ports are
not sequential, multiple interface vfc commands are required.
Example 2: Creating and binding nonconsecutive VFC ports
Nexus5020# configure terminal
Nexus5020(config)# interface vfc 1
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 2
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 3
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 4
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 5
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 6
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 10
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 20
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 21
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 22
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 23
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 24
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 25
Nexus5020(config-if)# bind interface ethernet
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 1-6
Nexus5020(config-if)# no shutdown
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 10
Nexus5020(config-if)# no shutdown
Nexus5020(config-if)# exit
Nexus5020(config)# interface vfc 20-25
Nexus5020(config-if)# no shutdown
Nexus5020(config-if)# exit
434
Best practices
1/1
1/2
1/3
1/4
1/5
1/6
1/10
1/20
1/21
1/22
1/23
1/24
1/25
7.
Enable the FC ports.
In this example, FC ports 2/1 through 2/8 are enabled.
Nexus5010(config)# interface fc 2/1-8
Nexus5010(config-if)# no shutdown
Nexus5010(config-if)# exit
Nexus5010(config)# exit
8.
Copy the running configuration to the startup configuration location.
Nexus5010# copy running-config startup-config
[########################################] 100%
9.
Copy the running configuration to a backup location.
Nexus5010# copy running-config ftp://10.10.20.1/backup.txt
10. Verify the configuration.
Nexus5010# show interface brief
Nexus5010# show running-config
SAN scaling
When you expand a topology, avoid making changes that disrupt the original design goals. If data access
requirements have changed, consider migrating to a topology that meets the current needs.
A high-availability SAN design accommodates a nondisruptive expansion, see SAN fabric topologies on
page 24.
CAUTION:
Hewlett Packard Enterprise highly recommends that you stop all I/O activity and back up all data
before adding switches to the fabric.
To expand a SAN:
•
Use switches with a higher port count.
•
Increase the number of switches.
To add switches to an existing fabric, ensure that the new configuration conforms to fabric rules. See
the following fabric rules sections:
◦
Fabric rules on page 161, for H-series switches
◦
Fibre Channel switch fabric rules on page 118, for B-series switches
◦
Fibre Channel switch fabric rules on page 149, for C-series switches
•
Add another fabric as a high-availability NSPOF solution.
•
Implement Fibre Channel routing, see Fibre Channel routing on page 46.
SAN scaling
435
•
Deploy multiple independent SANs.
•
Migrate to a different SAN topology, see Topology migration on page 44.
When adding new switches, avoid fabric segmentation. For more information, see Fabric segmentation
errors on page 437.
Cascaded fabric expansion
Expand a cascaded fabric by connecting a new switch to an available port on an existing switch. If no
ports are available, remove devices from an existing switch, connect the new switch to those ports, and
then reconnect the devices to the new switch.
Meshed fabric expansion
Expand a meshed fabric by connecting a new switch to available ports on an existing switch. If no ports
are available, remove devices from an existing switch, connect the new switch to those ports, and then
reconnect the devices to the new switch. Ensure that multiple paths (ISLs) connect the new switch to the
meshed fabric.
Ring fabric expansion
Expand a ring fabric by adding a switch to the ring.
Add new switches cascaded off the ring, up to the maximum number of switches supported in a single
fabric. When expanding outside the ring, ensure that communicating devices are connected by no more
than seven hops.
Core-edge fabric expansion
Expand a core-edge SAN fabric by adding edge switches. Connect edge switches to available ports on
the backbone switches.
If the current SAN contains only one core switch, add another. Connect edge switches to ports on the
new core switch.
SAN fabric merging
You can merge independent fabrics into a single, larger fabric. Merging enables you to:
•
Provide more resources to independent SAN fabrics.
•
Share the resources in two or more fabrics.
•
Make information in one SAN available to servers in another SAN.
•
Connect geographically dispersed fabrics into a single SAN.
During initial login, the discovery process determines whether the fabrics are compatible. If not,
segmentation occurs and they continue to operate as separate fabrics, see Fabric segmentation errors
on page 437.
When fabrics merge, the zone configuration databases are updated to include the zone configurations of
each fabric. If a nonzoned fabric merges with a zoned fabric, all zoning information is proliferated to the
nonzoned fabric switches. A zone configuration that is enabled at the time of the merge is also enabled
on the nonzoned fabric switches. Devices in the nonzoned fabric are not accessible until you add them to
the current configuration.
436
Cascaded fabric expansion
NOTE:
When enabling a new configuration, Hewlett Packard Enterprise strongly recommends that the fabric be
quiesced. Zone membership should not be changed for devices that are actively performing I/O in a
fabric. After the new zoning is enabled, an RSCN is sent to all nodes that have been registered to receive
the RSCN.
The following sections provide information to help you successfully merge SAN fabrics:
•
Fabric segmentation errors on page 437
•
Switch configuration parameters on page 437
•
Independent fabric merge on page 438
•
High-availability redundant fabric merge on page 438
Fabric segmentation errors
The following errors can cause fabric segmentation:
•
Zone type mismatch
The name of a zone object in one fabric is identical to the name of a different type of zone object in the
other fabric. For example, an object name on fabric A must not be an alias or configuration name in
fabric B; otherwise, the fabrics cannot merge.
•
Zone content mismatch
The definition of a zone object in one fabric is different from its definition in the other fabric. If an alias,
zone, or configuration name is the same on both fabric A and B, but the content or definition of the
objects is different, the fabrics cannot merge.
•
Zone configuration mismatch
Zoning is enabled for both fabrics, but the zone configurations are different. The fabrics cannot merge
until the zone configuration is disabled for one of the fabrics.
•
Duplicate IDs
Each switch in a fabric must have a unique domain ID; each switch in multiple fabrics of the SAN must
also have a unique ID. For example, if fabric A has five switches with domain IDs 1 through 5, and
fabric B has five switches with the same domain IDs, these two fabrics cannot merge until each switch
in both fabrics has a unique domain ID.
For port-level zoning, changing the domain IDs can disrupt device access. Port-level zones are based
on the domain ID and port number.
Switch configuration parameters
Mismatched switch parameters can cause a SAN merger to fail. The configuration settings for all switches
in the fabric must match, with the exception of the following parameters:
•
Switch name
•
IP address
•
Domain ID
Fabric segmentation errors
437
Independent fabric merge
Merge fabrics by disabling the effective configuration on one fabric and then connecting both fabrics. After
you connect the fabrics, devices in the second fabric are not accessible until you add them to the effective
configuration.
CAUTION:
When you disable the effective configuration, the fabric becomes accessible to all servers.
To merge two fabrics without disabling the effective configuration for entire fabrics, disable at least one
switch in each fabric or use an additional switch. Use the disabled switch to merge the fabrics and create
the new configuration.
High-availability redundant fabric merge
With redundant fabrics, you can merge a fabric by taking it offline and redirecting I/O to the other fabric.
Current I/O operations are not affected; however, during the merge, the hosts operate in degraded mode
without redundant data path protection. With proper planning, you can minimize downtime. After
completing and verifying the fabric merge, bring the first fabric online by restoring the I/O paths. After you
restore the I/O paths on the first fabric, you can repeat the merge process for the second fabric.
Merging high-availability fabrics example
In the following procedure, the SAN consists of fabric A and a redundant fabric B. Each of these fabrics is
merged with a SAN consisting of fabrics C and D.
•
Identify and resolve any issues that can cause fabric segmentation.
•
Verify that each fabric provides a redundant path to all attached devices.
•
Verify that paths are open to each device that must remain online during the merge.
•
Select fabrics for merging, for example, fabric A with fabric C.
•
Close all active paths on the fabric selected for merging and prepare devices for downtime. For
example, use multipathing software to redirect I/O by performing a failover to the alternate path.
•
Verify that the fabric selected for merging has no I/O activity.
•
Connect the selected fabrics (fabric A and fabric C).
•
Verify that the newly merged fabric contains all switches and that the zoning has merged correctly.
•
Restore I/O operations on the new fabric from the multipathing software console.
•
Verify that paths are open and restored for each device.
•
Ensure that all paths and I/O operations have been restored.
SAN infrastructure monitoring
Hewlett Packard Enterprise recommends use of the Intelligent Infrastructure Analyzer Software (IIAS) to
monitor and diagnose the physical layer of SANs in real-time, with an emphasis on the SFP transceivers
utilized in Fibre Channel switches. The solution is highly beneficial for enterprise SANs, where SAN
management can be cumbersome and tedious. IIAS is intended for customers who utilize HPE storage
hardware in their SAN.
HPE IIAS uses industry-standard protocols (such as SNMP, SMI-S, Telnet) to monitor the physical layer
(SFP transceivers) of a SAN. It diagnoses changes/events in SFP states and characteristics, and
presents SAN topology, inventory, and diagnostic information to the user in real-time. IIAS enables you to:
438
Independent fabric merge
•
Discover and collect data for B-Series and H-Series switches in a SAN
•
Periodically monitor a SAN at configured intervals using an active profile
•
Monitor or diagnose degrading or failing SFPs in an active profile
•
Generate current and historical reports
•
Notify the user of any change in the topology or SAN component state
•
Provide a SAN hardware summary in terms of component inventory
For additional information about IIAS, see the IIAS website at http://www.hpe.com/info/iias
Best practices
439
Support and other resources
Accessing Hewlett Packard Enterprise Support
•
For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
http://www.hpe.com/assistance
•
To access documentation and support services, go to the Hewlett Packard Enterprise Support Center
website:
http://www.hpe.com/support/hpesc
Information to collect
•
Technical support registration number (if applicable)
•
Product name, model or version, and serial number
•
Operating system name and version
•
Firmware version
•
Error messages
•
Product-specific reports and logs
•
Add-on products or components
•
Third-party products or components
Accessing updates
•
Some software products provide a mechanism for accessing software updates through the product
interface. Review your product documentation to identify the recommended software update method.
•
To download product updates:
Hewlett Packard Enterprise Support Center
www.hpe.com/support/hpesc
Hewlett Packard Enterprise Support Center: Software downloads
www.hpe.com/support/downloads
Software Depot
www.hpe.com/support/softwaredepot
•
To subscribe to eNewsletters and alerts:
www.hpe.com/support/e-updates
•
440
To view and update your entitlements, and to link your contracts and warranties with your profile, go to
the Hewlett Packard Enterprise Support Center More Information on Access to Support Materials
page:
Support and other resources
www.hpe.com/support/AccessToSupportMaterials
IMPORTANT:
Access to some updates might require product entitlement when accessed through the Hewlett
Packard Enterprise Support Center. You must have an HPE Passport set up with relevant
entitlements.
Customer self repair
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a
CSR part needs to be replaced, it will be shipped directly to you so that you can install it at your
convenience. Some parts do not qualify for CSR. Your Hewlett Packard Enterprise authorized service
provider will determine whether a repair can be accomplished by CSR.
For more information about CSR, contact your local service provider or go to the CSR website:
http://www.hpe.com/support/selfrepair
Remote support
Remote support is available with supported devices as part of your warranty or contractual support
agreement. It provides intelligent event diagnosis, and automatic, secure submission of hardware event
notifications to Hewlett Packard Enterprise, which will initiate a fast and accurate resolution based on your
product's service level. Hewlett Packard Enterprise strongly recommends that you register your device for
remote support.
If your product includes additional remote support details, use search to locate that information.
Remote support and Proactive Care information
HPE Get Connected
www.hpe.com/services/getconnected
HPE Proactive Care services
www.hpe.com/services/proactivecare
HPE Proactive Care service: Supported products list
www.hpe.com/services/proactivecaresupportedproducts
HPE Proactive Care advanced service: Supported products list
www.hpe.com/services/proactivecareadvancedsupportedproducts
Proactive Care customer information
Proactive Care central
www.hpe.com/services/proactivecarecentral
Proactive Care service activation
www.hpe.com/services/proactivecarecentralgetstarted
Warranty information
To view the warranty for your product, see the Safety and Compliance Information for Server, Storage,
Power, Networking, and Rack Products document, available at the Hewlett Packard Enterprise Support
Center:
www.hpe.com/support/Safety-Compliance-EnterpriseProducts
Customer self repair
441
Additional warranty information
HPE ProLiant and x86 Servers and Options
www.hpe.com/support/ProLiantServers-Warranties
HPE Enterprise Servers
www.hpe.com/support/EnterpriseServers-Warranties
HPE Storage Products
www.hpe.com/support/Storage-Warranties
HPE Networking Products
www.hpe.com/support/Networking-Warranties
Regulatory information
To view the regulatory information for your product, view the Safety and Compliance Information for
Server, Storage, Power, Networking, and Rack Products, available at the Hewlett Packard Enterprise
Support Center:
www.hpe.com/support/Safety-Compliance-EnterpriseProducts
Additional regulatory information
Hewlett Packard Enterprise is committed to providing our customers with information about the chemical
substances in our products as needed to comply with legal requirements such as REACH (Regulation EC
No 1907/2006 of the European Parliament and the Council). A chemical information report for this product
can be found at:
www.hpe.com/info/reach
For Hewlett Packard Enterprise product environmental and safety information and compliance data,
including RoHS and REACH, see:
www.hpe.com/info/ecodata
For Hewlett Packard Enterprise environmental information, including company programs, product
recycling, and energy efficiency, see:
www.hpe.com/info/environment
Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us
improve the documentation, send any errors, suggestions, or comments to Documentation Feedback
(docsfeedback@hpe.com). When submitting your feedback, include the document title, part number,
edition, and publication date located on the front cover of the document. For online help content, include
the product name, product version, help edition, and publication date located on the legal notices page.
442
Regulatory information
Download PDF
Similar pages