HP 4400 HP StorageWorks Fabric OS 6.4.0c Release Notes (5697-0703, September 2 - Page 41

The disable EE interface CLI, Fabric OS Encryption Administrator's, Guide

Page 41 highlights

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 initEE. After initEE, regEE and enableEE, run cryptocfg -recovermasterkey to recover the master key previously backed up, or in the case of fresh install run cryptocfg - genmasterkey to generate a new master key. If you are using SKM, establish a trusted link with SKM again. Certificate exchange between key vaults and switches are not required in this case. • The disable EE interface CLI cryptocfg --disableEE [slot no] should be used only to disable encryption and security capabilities of the EE from the Fabric OS Security Admin in the event of a security compromise. When disabling the encryption capabilities of the EE using the noted commands, the EE should not be hosting any CTCs. Ensure that all CTCs hosted on the HP Encryption Switch or HP Encryption Blade are either removed or moved to a different EE in the HA Cluster or EG before disabling the encryption and security capabilities. • Whenever initNode is performed, new certificates for CP and KAC (SKM) are generated. Hence, each time InitNode is performed, the new KAC Certificate must be loaded onto key vaults for (SKM. Without this step, errors occur, such as key vault not responding and ultimately key archival and retrieval problems. • The HTTP server should be listening to port 9443. SKM is supported only when configured to port 9443. • Configuring a Brocade group on SKM: As described in the Fabric OS Encryption Administrator's Guide, a Brocade group needs to be configured on SKM (under Local Users & Groups) for managing all keys generated by Brocade encryption switches and blades. It is important to note that the name for this group is case sensitive and must be "brocade," not "Brocade." • When all nodes in an EG (HA Cluster or DEK Cluster) are powered down (due to catastrophic disaster or a power outage to the data center) and later nodes come back online (in the event of the Group Leader (GL) node failing to come back up or the GL node being kept powered down), the member nodes lose information and knowledge about the EG. This leads to no crypto operations or commands (except node initialization) being available on the member nodes after the powercycle. This condition persists until the GL node is back online. • Workaround. In the case of a data center power down, bring the GL node online first, before bringing the other member nodes online. In the event of the GL node failing to come back up, the GL node can be replaced with a new node. The following are the procedures to allow an EG to function with existing member nodes and to replace the failed GL node with a new node: HP StorageWorks Fabric OS 6.4.0c Release Notes 41

  • 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

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
slot-
poweroff
/
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
initEE
. After
initEE
,
regEE
and
enableEE
, run
cryptocfg –recovermasterkey
to recover the master
key previously backed up, or in the case of fresh install run
cryptocfg – genmasterkey
to
generate a new master key. If you are using SKM, establish a trusted link with SKM again. Certi-
ficate exchange between key vaults and switches are not required in this case.
The disable EE interface CLI
cryptocfg --disableEE [slot no]
should be used only to
disable encryption and security capabilities of the EE from the Fabric OS Security Admin in the
event of a security compromise. When disabling the encryption capabilities of the EE using the
noted commands, the EE should not be hosting any CTCs. Ensure that all CTCs hosted on the HP
Encryption Switch or HP Encryption Blade are either removed or moved to a different EE in the
HA Cluster or EG before disabling the encryption and security capabilities.
Whenever
initNode
is performed, new certificates for CP and KAC (SKM) are generated. Hence,
each time
InitNode
is performed, the new KAC Certificate must be loaded onto key vaults for
(SKM. Without this step, errors occur, such as key vault not responding and ultimately key
archival and retrieval problems.
The HTTP server should be listening to port 9443. SKM is supported only when configured to port
9443.
Configuring a Brocade group on SKM: As described in the
Fabric OS Encryption Administrator's
Guide
, a Brocade group needs to be configured on SKM (under Local Users & Groups) for man-
aging all keys generated by Brocade encryption switches and blades. It is important to note that
the name for this group is case sensitive and must be
brocade,
not
Brocade.
When all nodes in an EG (HA Cluster or DEK Cluster) are powered down (due to catastrophic
disaster or a power outage to the data center) and later nodes come back online (in the event of
the Group Leader (GL) node failing to come back up or the GL node being kept powered down),
the member nodes lose information and knowledge about the EG. This leads to no crypto operations
or commands (except node initialization) being available on the member nodes after the power-
cycle. This condition persists until the GL node is back online.
Workaround.
In the case of a data center power down, bring the GL node online first, before
bringing the other member nodes online.
In the event of the GL node failing to come back up, the GL node can be replaced with a new
node.
The following are the procedures to allow an EG to function with existing member nodes and
to replace the failed GL node with a new node:
HP StorageWorks Fabric OS 6.4.0c Release Notes
41