Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition | |||
|
|
Solution Type Problem Resolution Sure Solution 1010855.1 : Sun Storage 3310/3320/3510/3511 Arrays:Identifying and Resolving an Incorrect "Controller Unique Identifier"
PreviouslyPublishedAs 214991
Applies to:Sun Storage 3310 SCSI ArraySun Storage 3320 SCSI Array Sun Storage 3510 FC Array Sun Storage 3511 SATA Array All Platforms Symptoms{SYMPTOM}Occasionally, as a result of some maintenance operation or cloning NVRAM from one Sun Storage 3310/3320/3510/3511 array to another, the following are 2 issues may occur: 1. Multiple arrays will exhibit the same Ethernet or MAC address. This document will explain why this problem happens, and includes steps to resolve the above. Changes{CHANGE}The Controller Unique Identifier, hence referred to as CUI, is used to create Ethernet (MAC) addresses and worldwide names. The
CUI is by default generated from the chassis serial number. On a
working array, if this CUI is changed, both the MAC address as well as
the worldwide names will change thereby causing problems from the host
end. We must ensure that the CUI always remains the same after any maintenance activity for smooth operation of the array. Cause{CAUSE}Explanation for the above two issues:1. Multiple arrays will exhibit the same Ethernet or MAC address. This problem may happen when we use the cloning feature of these type of arrays where we can duplicate the NVRAM settings from one array
to another. We can save the NVRAM or the configuration details from one
array and use the same to create the same configuration on the other
array. By doing this, we also duplicate the CUI and the MAC address. Hence we could have more than one array with same MAC address. 2. The unique worldwide names may change resulting in change of DID's (device ids) which are used for Sun Cluster configurations. All the controller FRUs that come from logistics have their
controller unique identifier field set to "0" . When this controller
is used as a replacement FRU, it inherits the "unique identifier" from
the primary controller, in the case of a dual controller configuration, or
the chassis serial number becomes the controller unique identifier, in the case of a single controller or scenarios where the primary controller is also having problems. The bottom line is that during a controller replacement or
cloning, we must ensure that the CUI is set to the same value as
the array chassis serial number. Failing to do so will result in either multiple arrays having the same ethernet address, or the worldwide names of the logical drives will change. SolutionResolutionIf one of these problems occurs, perform the following steps to resolve this issue :
NOTE 1: If the midplane is replaced, then the controller unique identifier will change and in this case, if we are running Sun Cluster, then we would have to manually recreate the DID's for Sun Cluster to work normally.
NOTE 2: A non-zero value should be specified only if the chassis has been replaced but the original CUI has to be retained: for example, in a Sun Cluster configuration to maintain the same DID's. This practice is not recommended as it can lead to problems and confusion in the future. On the next available outage, the DID's must be manually fixed for the cluster to work normally. Additional Information: See the Sun StorEdge[TM] 3000 Family FRU Installation Guide: 816-7326 for additional data on controller, midplane and chassis replacements. minnow, 3510, 3310, 3511, 3320, MAC, ethernet, nvram, controller, unique-identifier Change History Date: 2010-07-06 User Name: susan.copeland@oracle.com Action: Currency & Update Attachments This solution has no attachment |
||||||||||||
|