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-71-2201583.1
Update Date:2016-11-07
Keywords:

Solution Type  Technical Instruction Sure

Solution  2201583.1 :   Device Interface Warning On all blades in Enclosure  


Related Items
  • BNS Platform Hardware
  •  
Related Categories
  • PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
  •  




In this Document
Goal
Solution


Created from <SR 3-13081510311>

Applies to:

BNS Platform Hardware - Version DSR 3.0 and later
Information in this document applies to any platform.

Goal

What is a possible cause of all blades in the enclosure showing eth02 is down .

sycheck shows device interface warning alarm:

TIMESTAMP: 2016-07-26 11:00:22.948 UTC
NETWORK_ELEMENT: network_element
SERVER: servername
SEQ_NUM: 14153
EVENT_NUMBER: 32513
SEVERITY: MINOR
PRODUCT: TPD
PROCESS: cmplatalarm
TYPE: PLAT
INSTANCE: hrDeviceDescr=eth02|hrDeviceErrors=slave_alarm
NAME: Device Interface Warning
DESCR: Device Interface Warning
ERR_INFO:
GN_WARNING/WRN Platform detected an error condition [cmplatalarm.cxx:194]
^^ Additional details captured in /var/TKLC/log/syscheck/fail_log (timestamp: 1469530822) [cmplatalarm.cxx:198]
^^ [6105:cmplatalarm.cxx:200]

Solution

Verifying possible Cause
Below shows that links are down due in Uplink Failure Detection
--------------------------------------------------------------------
The device interface warning alarm cleared when up link was removed but it appeared again when we added back.

# config
(config)# no uplink-failure-detection track 1
(config)# end
#

Check one of the servers (ie., login a run syscheck to see if eth02 is still down)

Add the command back on the switch

# config
(config)# uplink-failure-detection track 1 links-to-monitor 17 links-to-disable 1-16
(config)# end
#

===================================================================================================================


Verifying cause of uplink failure
Below shows that the other end of the cable for the uplink port can be in a state that causes the uplink to be down
-----------------------------------------------------------------------------
e.g.,

aggswitch#show int te 1/51
TenGigabitEthernet1/51 is down, line protocol is down (err-disabled) <----------------------------------------
 Hardware is Ten Gigabit Ethernet Port, address is 5057.wxyz.abcd (bia 5057.wxyz.abcd)
 Description: 802.1q_trunk_between_AggSwitch_and_EncSwitch2 <-----------------------------------------------------
 MTU 9198 bytes, BW 10000000 Kbit, DLY 10 usec,
  reliability 240/255, txload 1/255, rxload 1/255
--More--

or

AggSwitch#show int te 1/51
TenGigabitEthernet1/51 is down, line protocol is down (notconnect) <--------------------------
 Hardware is Ten Gigabit Ethernet Port, address is 649e.cdef.uvwx (bia 649e.cdef.uvwx)
 Description: 802.1q_trunk_between_AggSwitch_and_EncSwitch2 <----------------------------------
 MTU 9198 bytes, BW 10000000 Kbit, DLY 10 usec,
  reliability 255/255, txload 1/255, rxload 1/255
 --More--


(notconnect) - this shows a layer 1 issue and suggests the cable is not connected.
connecting the capable addressed this issue.

(err-disabled) - further investigation is needed to confirm the reason for this state.
The reason can be determined with:

# show interfaces status err-disabled

Often this shows flapping for the port and can point to bad cable (which means cable should be replaced) or some other issue.

The port can be returned to service by bringing it up.

# config t
# int te 1/52
# no shut
# end

If problem persists after replacing cable further investigation may be needed.

 


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback