HP 4400 HP B-series Fabric OS 6.4.1b Release Notes (5697-0886, March 2011-incl - Page 38

Each LUN is uniquely identified by the HP Encryption Switch or HP Encryption Blade using

Page 38 highlights

• Configuration of crypto targets on HP StorageWorks encryption switches or encryption blades is accomplished in two stages: entering the configuration changes and issuing a commit operation. Previous to Fabric OS 6.3.1a, if the data encryption group (Encryption Group) became incomplete (one or more members became inaccessible due to network problems and the encryption group becomes degraded) between these two stages, the commit operation was still executed. While this did not result in any issue for the configured host and targets, it could lead to configuration changes being applied to only a subset of the encryption switches in the encryption group. This was a rare situation that had only been seen in test environments. This issue was resolved in Fabric OS 6.3.1a. • If the data encryption group (Encryption Group) gets into a state where the Group Leader encryption switch reports that another encryption switch is NOT a member node of the encryption group, and the encryption switch member node still indicates that it IS part of the encryption group, the following recovery action can be performed to re-merge the nodes into the encryption group: 1. On the Group Leader encryption switch, execute the CLI cryptocfg -dereg -membernode command. 2. Wait for 30 seconds. 3. Execute the CLI cryptocfg -reg -membernode command. This is a rare situation that has been noted in a test environment where there were intermittent management network connectivity problems. • To remove access between a given initiator and target, you must not only remove the active zoning information between the initiator and target, but must also remove the associated CTCs, which in turn removes the associated frame redirection zone information. Make sure to back up all data before taking this action. • Before committing configurations or modifications to the CTC or LUNs on an HP Encryption Switch or HP Encryption Blade, make sure that there are no outstanding zoning transactions in the switch or fabric. Failure to do so results in the commit operation for the CTC or LUNs failing and may cause the LUNs to be disabled. The user can check for outstanding zoning transactions by issuing the CLI cfgtransshow command : DCX_two:root> cfgtransshow There is no outstanding zoning transaction • Each LUN is uniquely identified by the HP Encryption Switch or HP Encryption Blade using the LUN serial number. The LUN serial numbers must be unique for LUNs exposed from the same target port. The LUN serial numbers must also be unique for LUNs belonging to different target ports in nonmultipathing configurations. Failure to ensure unique LUN serial numbers results in nondeterministic behavior and may result in faulting of the HP Encryption Switch or HP Encryption Blade. • When creating an HA cluster or EG with two or more HP Encryption Switch/Encryption Blades, the GE ports (I/O sync links) must be configured with an IP address for the eth0 and eth1 Ethernet interfaces using ipaddrset. In addition, the eth0 and eth1 Ethernet ports should be connected to the network for redundancy. These I/O sync links connections must be established before any Re-Key, First Time Encryption, or enabling EE for crypto operations. Failure to do so results in HA Cluster creation failure. If the IP address for these ports is configured after the EE was enabled for encryption, HP Encryption Switch needs to be rebooted and Encryption Blades should be slotpoweroff/slotpoweron to sync up the IP address information to the EEs. If only one Ethernet port is configured and connected to a network, data loss or suspension of Re-Key may occur when the network connection toggles or fails. • initEE removes the existing master key or link key. Backup the master key by running cryptocfg -exportmasterkey and cryptocfg -export -currentMK before running 38

  • 1
  • 2
  • 3
  • 4
  • 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
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75

Configuration of crypto targets on HP StorageWorks encryption switches or encryption blades
is accomplished in two stages: entering the configuration changes and issuing a commit
operation. Previous to Fabric OS 6.3.1a, if the data encryption group (Encryption Group)
became incomplete (one or more members became inaccessible due to network problems
and the encryption group becomes degraded) between these two stages, the commit operation
was still executed. While this did not result in any issue for the configured host and targets,
it could lead to configuration changes being applied to only a subset of the encryption switches
in the encryption group. This was a rare situation that had only been seen in test environments.
This issue was resolved in Fabric OS 6.3.1a.
If the data encryption group (Encryption Group) gets into a state where the Group Leader
encryption switch reports that another encryption switch is NOT a member node of the
encryption group, and the encryption switch member node still indicates that it IS part of the
encryption group, the following recovery action can be performed to re-merge the nodes into
the encryption group:
1.
On the Group Leader encryption switch, execute the CLI
cryptocfg
dereg
membernode <WWN of member node>
command.
2.
Wait for 30 seconds.
3.
Execute the CLI
cryptocfg
reg
membernode <WWN membernode>
<certificate file name> <ipaddr of member node>
command.
This is a rare situation that has been noted in a test environment where there were intermittent
management network connectivity problems.
To remove access between a given initiator and target, you must not only remove the active
zoning information between the initiator and target, but must also remove the associated
CTCs, which in turn removes the associated frame redirection zone information. Make sure
to back up all data before taking this action.
Before committing configurations or modifications to the CTC or LUNs on an HP Encryption
Switch or HP Encryption Blade, make sure that there are no outstanding zoning transactions
in the switch or fabric. Failure to do so results in the commit operation for the CTC or LUNs
failing and may cause the LUNs to be disabled. The user can check for outstanding zoning
transactions by issuing the CLI
cfgtransshow
command :
DCX_two:root> cfgtransshow
There is no outstanding zoning transaction
Each LUN is uniquely identified by the HP Encryption Switch or HP Encryption Blade using
the LUN serial number. The LUN serial numbers must be unique for LUNs exposed from the
same target port. The LUN serial numbers must also be unique for LUNs belonging to different
target ports in nonmultipathing configurations. Failure to ensure unique LUN serial numbers
results in nondeterministic behavior and may result in faulting of the HP Encryption Switch or
HP Encryption Blade.
When creating an HA cluster or EG with two or more HP Encryption Switch/Encryption Blades,
the GE ports (I/O sync links) must be configured with an IP address for the
eth0
and
eth1
Ethernet interfaces using
ipaddrset
. In addition, the
eth0
and
eth1
Ethernet ports should
be connected to the network for redundancy. These I/O sync links connections must be
established before any Re-Key, First Time Encryption, or enabling EE for crypto operations.
Failure to do so results in HA Cluster creation failure. If the IP address for these ports is
configured after the EE was enabled for encryption, HP Encryption Switch needs to be rebooted
and Encryption Blades should be
slotpoweroff
/
slotpoweron
to sync up the IP address
information to the EEs. If only one Ethernet port is configured and connected to a network,
data loss or suspension of Re-Key may occur when the network connection toggles or fails.
initEE
removes the existing master key or link key. Backup the master key by running
cryptocfg
exportmasterkey
and
cryptocfg
export
currentMK
before running
38