How to identify a SFP failure on the NPM

book

Article ID: 168019

calendar_today

Updated On:

Products

XOS

Issue/Introduction

How to identify a SFP failure on the NPMN/A

Cause

Sometimes a customer needs to verify that an SFP has failed on an NPM 82xx module. Such verification can be done through the /var/log/messages file.

Resolution

In some case customers may see the interface flap happening on a regular basis.

The log events would look like as follows:

Jul 21 16:17:03 cbs cbsalarmmond[2700]: [I] Received fault reply msg w/ 1 entries, seqnum=0
Jul 21 16:17:03 cbs cbsalarmmond[2700]: [I] NP3 WAN Link 5: Down
Jul 21 16:17:04 npm3 tPhyTimerProc: [I] ethsw_port_down: 3.5: down
Jul 21 16:17:04 cbs cbsirmd[2495]: [I] Obj PhysIntfStateTable slot:3 port:5 state:up modified in state sUp
Jul 21 16:17:04 cbs cbsirmd[2495]: [I] PhysIntf 3/5 state changed to backup
Jul 21 16:17:04 cbs cbsirmd[2495]: [I] PhysIntfState slot:3 port:5 state:down
Jul 21 16:17:04 cbs cbsirmd[2495]: [I] LogIntf slot:3 port:5 chan:0-0 chan not used type:gw cct:1031
Jul 21 16:17:08 npm3 tPhyTimerProc: [I] ethsw_port_up: 3.5: up.
Jul 21 16:17:08 cbs cbshmonitord[2531]: [N] hm_process_report_data Violation (s=1, no alarm) cleared: module:3, item:2425 (H_ID_WAN_LINK5_FAIL)
Jul 21 16:17:08 cbs cbsalarmmond[2700]: [I] Received fault reply msg w/ 1 entries, seqnum=0
Jul 21 16:17:08 cbs cbsalarmmond[2700]: [I] NP3 WAN Link 5: Up



The troubleshooting technique is as follows:
  • Check the interface status from the other end (switch) and if no action has been performed, then check the wiring (good or not).
  • Exchange the SFP of the failing port with a one known to be working.
  • If the problem is resolved by exchanging the SFP and the fault follows the SFP which was in this case in port 3/5 you should then contact Crossbeam Technical Support to request a replacement SFP unit.

Workaround

N/A