Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1010855.1
Update Date:2013-08-12
Keywords:

Solution Type  Problem Resolution Sure

Solution  1010855.1 :   Sun Storage 3310/3320/3510/3511 Arrays: Identifying and Resolving an Incorrect "Controller Unique Identifier"  


Related Items
  • Sun Storage 3511 SATA Array
  •  
  • Sun Storage 3310 Array
  •  
  • Sun Storage 3510 FC Array
  •  
  • Sun Storage 3320 SCSI Array
  •  
Related Categories
  • PLA-Support>Sun Systems>DISK>Arrays>SN-DK: SE31xx_33xx_35xx
  •  

PreviouslyPublishedAs
214991


Applies to:

Sun Storage 3310 Array - Version Not Applicable and later
Sun Storage 3320 SCSI Array - Version Not Applicable and later
Sun Storage 3510 FC Array - Version Not Applicable and later
Sun Storage 3511 SATA Array - Version Not Applicable and later
All Platforms

Symptoms

Occasionally, as a result of some maintenance operation or cloning NVRAM from one Sun Storage 3310/3320/3510/3511 Array to another, the following two issues may occur:

  • Multiple arrays will exhibit the same Ethernet or MAC address.
  • The unique worldwide names may change resulting in change of DIDs (device ids) which are used for Solaris Cluster configurations.

This document will explain why this problem happens, and includes steps to resolve it.

Changes

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 at the host end.

For smooth operation of the array, we must ensure that the CUI always remains the same after any maintenance activity.

Cause

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 this 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 the same MAC address.

 

The unique worldwide names may change resulting in change of DIDs (device ids) which are used for Solaris Cluster configurations.

All the controller FRUs that come from Logistics have their controller unique identifier field set to "0". When a new 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.

Solution

 If one of these problems occurs, perform the following steps to resolve this issue :

  1. Telnet to the array.
  2. At the Main Menu, select View and Edit configuration parameters.
  3. On the resulting menu, select Controller Parameters.
  4. From the Controller Parameters menu, select Controller Unique Identifier.
  5. Enter the value 0 to automatically read the chassis serial number from the midplane or type the hex value for the original serial number of the chassis. (Use the hex value of the original serial number when the midplane has been replaced.)
  6. Reset the array.

If the midplane is replaced, then the controller unique identifier will change. In this case, if you are running Solaris Cluster, you would otherwise have to manually recreate the DIDs for Solaris Cluster to work normally.

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 Solaris Cluster configuration to maintain the same DIDs.

This practice is not recommended as it can lead to problems and confusion in the future.

On the next available outage, the DIDs must be manually fixed for the Cluster to work normally.



Additional Information:

See the Sun StorEdge 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
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback