Advice on SNMP MIB trap organization

Question

I am looking for some advice on SNMP MIB trap organization or best practices. I haven't found any material describing real world usage and expectations.

I have only briefly worked with SNMP in the past, and mostly just get/set, I have never had to deal with traps before.

Let me explain...

I recently joined a company and needed to look at their MIB, but the traps in it are not what I expected.

For each trap that raises an alarm condition (eg. ‘over X threshold’ - severity critical, id 100) has a completely separate trap for a clear (‘over X threshold clear’- severity clear, id 134). Each one of the traps has an arbitrary ‘trap-id’ assigned to it with no meaning or relationship information encoded in it. The only way one knows that trap 134 clears trap 100 is to look at the textual name of the trap. This just doesn’t seem right.

For example, the fan failure trap is as follows (edited for brevity):

    fooTrapFanFailure NOTIFICATION-TYPE
        OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
        DESCRIPTION   "Fan failure, trap-id 105, severity major"
        ::= { fooTraps 8 }

    fooTrapFanFailureClear NOTIFICATION-TYPE
        OBJECTS {StampID, SerialNumber, Name, TrapID, Severity}
        DESCRIPTION  "Fan failure clear, trap-id 132, severity informational"
        ::= { fooTraps 11 }

The only way I know that 132 is a clear for 105 is to manually read the MIB or programmatically scan the MIB and build a table based on the trap name. This case is even more goofy as the Clear trap shows up with an ‘informational’ severity.

I expected when an ‘over X threshold’ trap-id 100 is raised, it would be sent with its severity set to say ‘critical’ and when it clears, the very same trap-id 100 would be sent with a severity of ‘clear’.

Or it would be even better if there was just one generic alarm trap which contains the trap-id and severity, instead of the my 65 or so unique traps.

So, in short, the question is:

Is this 'two trap, one to raise and one to clear' normal?

Answer 1

It's not normal but it's OK. I can see why they might have done it that way, it is easy to assign colors in HP OV NNM based on OID (don't know the exact version but it worked in the year 2000). Or else you might have to parse the packet to display colors on the Manager/Management station.

Generally it is good idea to use trap status as part of the trap binding.

Answer 2

I use my Mib files with the SNMPc. My file has only one trap EventOccured and all other logic (correlation) made by SNMPc filters. I use Severity='CL' to clear traps. So don't understand what for you need a Severity var in the "fooTrapFanFailureClear" trap?