False Module removed alarm in Spectrum

Products

• Spectrum
• Network Observability

Issue/Introduction

• Alerts received for module removal, even though the specified port is not present on the device.
• We have had the situation again that a "Module removed" alarm has occurred during configuration changes (creation of a vlan). According to the network colleagues, these modules are not dependent on any of the vlan that was created.

• It is also noticeable that the Removed Alarm is not cleared and must then be closed manually.
  The whole thing is a bit unfortunate, because the "Module removed" alarm generally leads to a notification to the standby.
  In this case it is a standard Cisco Device:
  
  

 

Environment

Release : ANY Spectrum Version

Cause

 Incorrect mib value.

Resolution

• These alarms are generated from the mib values supplied by Cisco. Internal Module Status (0x12e66) attribute which determines the module pulled alarm, is getting its table read from EntPhysicalEntry 1.3.6.1.2.1.47.1.1.1.1. Specifically we're looking for the entry for entPhysicalIndex. If it exists, the module is considered ONLINE. If it is missing from the EntPhysicalEntry, then it is considered OFFLINE. You can also use MIB Tools and run getNext query on EntPhysicalEntry 1.3.6.1.2.1.47.1.1.1.1 for your Cisco devices to verify the state.
• I would assume that right now it shows as online, as directly after the module removed event we have a module online event, at the same exact time actually.
• However, the module online event (10fa9) does not clear the module removed event (10f6d) as only event "The module is present. Any existing 'Module Removal Detected' alarms have been cleared." (10fa8) does.
• Below is the entry for same in EvenDisp file. 
  
  

  /c/win32app/Spectrum/SS/CsVendor
  > grep -r "10f6d" .
  ./Cabletron/EventDisp:0x00010fa8 E 20 C 0x00010f6d
  

• To avoid the same situation, we could modify 10fa9 event to clear the 10f6d event.

Additional Information

If this problem happens again, please try to connect again via mibtools and see if the sysoid 1.3.6.1.2.1.47.1.1.1.1 can be read. If it cannot be read then it is a mib / firmware issue that should be reported to the vendor.