HP B-series Fabric OS 6.3.2e Release Notes (5697-1816, March 2012) - includes all 6.3.2x versions

6.2.x to 6.3.2. Note that the following procedure is required only under the above-mentioned
conditions.
1. Before the firmware upgrade, change the Failback Mode to manual for all containers
configured as auto. Take note of which Encryption Engines currently own which
containers.
2. Upgrade all nodes in the Encryption Group to Fabric OS 6.3.2, one node at a time.
3. After all nodes have been successfully upgraded, using the notes taken in step 1, manually
invoke the failback of the containers to the correct Encryption Engine using the command
cryptocfg -failback -EE <WWN of hosting node> [slot num] <WWN of
second node in HAC> [slot num].
4. Once the manual failback completes, change the Failback Mode back to auto from
manual, if it was changed in step 1.
• Avoid changing the configuration of any LUN that belongs to a CTC/LUN configuration while
the rekeying process for that LUN is active. If the user changes the LUN’s settings during
manual or auto, rekeying or First Time Encryption, the system reports a warning message
stating that the encryption engine is busy and a forced commit is required for the changes to
take effect. A forced commit command halts all active rekeying processes running in all CTCs
and corrupts any LUN engaged in a rekeying operation. There is no recovery for this type of
failure.
• Configuration of crypto targets on HP 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 has been 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 command cryptocfg –dereg
–membernode <WWN of member node>
2. Wait for 30 seconds.
3. Execute the CLI command cryptocfg –reg –membernode <WWN membernode>
<certificate file name> <ipaddr of member node>
This is a rare situation that has been noted in a test environment where there were intermittent
management network connectivity problems. A fix for this issue is in the Fabric OS 6.4.0
release.
• To remove access between a given initiator and target, the user must not only remove the
active zoning information between the initiator and target, but must also remove the associated
CTCs, which will in turn remove 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 command cfgtransshow:
DCX_two:root> cfgtransshow
Encryption behavior 35