False Card Down Alarms received when Cards do not exist on the Devices

Products

• VMware Smart Assurance

Issue/Introduction

This article helps track validity of cards based on the following symptoms:

• Cards are not present on the device, yet Smarts IP managers creates the cards. 
• These cards are further reported as DOWN based on the OID: .1.3.6.1.4.1.9.5.1.3.1.1.10 - module-status

Environment

Smarts 10.1.X, 24.3.X

Cause

In the SNMPWalk operation, if the following OIDs return positive values, it would mean that the device is exposing Card information:

• .1.3.6.1.4.1.9.5.1.3.1.1.2  # moduleType
• .1.3.6.1.4.1.9.5.1.3.1.1.13 # moduleName
• .1.3.6.1.4.1.9.5.1.3.1.1.17 # moduleModel
• .1.3.6.1.4.1.9.5.1.3.1.1.21 # moduleStandbyStatus
• .1.3.6.1.4.1.9.5.1.3.1.1.22 # moduleIPAddress
• .1.3.6.1.4.1.9.5.1.3.1.1.26 # moduleserialNumberString

Based on the online references, we can see that the ModuleType if not present is to be set to "2" (empty). Hence, if the module type returns a value other than 2, the respective instance is created in Smarts.

1.3.6.1.4.1.9.5.1.3.1.1.2
Module         CISCO-STACK-MIB (CISCO)
Nom            moduleType
Acces          readonly
Status         current
Description    The type of module.
Syntax         Enumeration (1-other, 2-empty, 3-wsc1000, ....etc)

 

Further, check for the module status using OID: .1.3.6.1.4.1.9.5.1.3.1.1.10 and evaluate the status based on the return values. (highlighted are the problematic values) 

moduleStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),      --> none of the following
ok(2),         --> status ok
minorFault(3), --> minor problem
majorFault(4)  --> major problem
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The operational status of the module. If the status is not ok, the value of moduleTestResult gives more detailed information about the modules failure condition(s)."

Resolution

Smarts is working as per the design here. 

If you observe any difference from the above, please raise a service request with Broadcom Support quoting this KB article (# 406675) for further investigation.