Sun StorageTek SL3000 Modular Library System
 
Sun StorageTek SL8500 Modular Library System
 

PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: SL3000-8500 Library
 

Redundant Electronics on SL8500, SL3000 command hung.

In this Document

Symptoms

Changes

Cause

Solution

Created from <SR 3-8666228251>

Applies to:

Symptoms

HSC command 'switch acs' failed to switch Redundant Electronics (RE feature) on SL3000 or SL8500.

Redundant Electronics on SL8500, SL3000 command hung.

Changes

 Ethernet cable was unplugged from library port 2B interface or network communication failed on port 2B.

Cause

Customer network failured from library to host.

Customer / FE running Redundant Electronics failover test.

Solution

Conclusive tests of failed ethernet network or cable was unplugged to the library port 2B. Below are results and work around. 

Hardware used for this test - SL3000, FRS 4.02 code, RE feature enabled. 

Side A - 10.80.40.107 Side B - 10.80.53.107   Step 1: 

•  Verified SL3000 CLI Interface-Active Card-Side A  , SL3000 CLI Interface-Standby Card-Side B.

•  Unplug ethernet cable from 2B side A.

•  HSC - Switch ACS.....

       From HSC: Nothing happened right away, but about a minute or two later I received:       14.40.41 STC03383 =SLS0000I SW ACS 01       14.42.21 STC03383 *=SLS0657E ACS 01 Station 10.80.40.107 not communicating       14.42.21 STC03383 *=SLS6012E ACS 01: Recovery of network connection to station 10.80.40.107 is now active       14.42.21 STC03383 =SLS1005I ACS 01 cannot switch; ACS disconnected or not Dual LMU       14.42.21 STC03383 =SLS0071I Unexpected RC 65156515 from LMURQST 

( note: this is the expected behavior as HSC and HBCR will not switch ACS based on network communication fault. HSC can no longer communicate with the library on what it believes to be the active LCU (A). HSC SWitch command just causes a reboot of the active LCU, in this case, LCUA. Since it can't get to LCUA, the switch fails. If the reboot were to happen as expected, then LCUB would take over. HBCR did not switch since its not a hardware fault. Work around is to manually switch controller (HBCR) at the library hardware. See step 2.) 

 Step 2: 

• Since side A communication is down, we used Side B to execute " reControl switch " from library cli. 

SL3000> recontrol switchConnection to 10.80.53.107 closed. Connecting to service@10.80.53.107... *******************************************************************          SL3000 CLI Interface-Active Card-Side B    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< verified side B is now active ******************************************************************* From HSC: 14.50.21 STC03383 =SLS6005I Network attach function READ failed for station 10.80.53.107 with errno 0 14.50.21 STC03383 *=SLS6012E ACS 01: Recovery of network connection to station 10.80.53.107 is now active. 

 Step 3: 

• Reconnected ethernet cable to side A

From HSC: 14.52.27 STC03383 =SLS6013I ACS 01: Recovery of network connection to station 10.80.40.107 successful 14.52.27 STC03383 =SLS1667I ACS 01: RE LIBID 1 is configured: Active B is ready, Standby is ready 14.52.44 STC03383 =SLS6013I ACS 01: Recovery of network connection to station 10.80.53.107 successful 14.52.44 STC03383 =SLS1666E ACS 01: RE LIBID 1 is configured: Active B is ready, Standby not ready 14.52.48 STC03383 =SLS0694I ACS 01: Switch has completed. 

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  As to Dual TCP/IP and RE ( with 4 cables ), we do not have that setup available for testing in our lab. But the principle remains the same with RE, where it will not failover based on ethernet communication fault. Since Dual TCP/IP feature uses active / active on ports 2B and 2A. The likely hood of library loosing all communication with host(s) are greatly reduced. 

This solution has no attachment