IMC trap adjustments

IMC is a great piece of code but it does require some adjustments from the defaults, specifically with some traps and their description, along with the default traps to alarms not always escalating what does require attention.

This post is a draft but I am using it to document things I would change on a factory default IMC WRT the above. You will notice that the adjustments that I make tend to revolve around making us of the parameters passed with the trap and making sure to highlight in bold the name of the feature / process which is rising the trap so that glancing through alarms lets you easily see what to look when analyzing on the CLI.

Loopback-detection: broadcast probing for loops when STP isnt.

Often enough I find myself recommending this function on edge devices as an additional peace-of-mind loop prevention measure. Loopback-detection sends a broadcast probe on the port and if it hears itself (by default same port, you can enable multi-port) it will block inbound packets until it stops hearing itself for a duration equal to 2 or 3 times the probe timer. Its a low maintenance feature which does its thing and auto recovers from incidents by default (you can have it action to shutdown too). IMC's descriptions are poor for the related traps and they are not escalated to alarms by default.

OID	1.3.6.1.4.1.25506.2.95.1.6.1
Original description	Loopback detected on an interface.
New description	LOOPBACK-DETECTION: Loop detected on interface $2.
Comment	We are being passed ifDescr (param 2) as a trap parameter - how about using it?

OID	1.3.6.1.4.1.25506.2.95.1.6.2
Original description	Trap message is generated when the loops on the interface are eliminated.
New description	LOOPBACK-DETECTION: Loop no longer exists on interface $2.
Comment	We are being passed ifDescr (param 2) as a trap parameter - how about using it?

Add the above to a Trap to Alarm object titled "Loopback-detection". You can also program OID.2 as a recovery for OID.1 if desirable.


Storm-constrain: metered broadcast/multicast/unicast with rising and falling thresholds and actions

OID	1.3.6.1.4.1.25506.2.66.3.6.1
Original description	Any type of the flux "$2" exceeds its upper limit "$3" on a port of Device "$R($a)".
New description	STORM-CONSTRAIN: $2(Broadcast:1,Multicast:2,Unicast:3) storm rising on port $c of device "$R($a)". Port status is $4(controlled:1,normal:2).
Comment	Lets use the parameter switch with parenthesis which the related falling trap below factory description was making us of. I wish HP reported ifDescr as a parameter for this trap: tracking by port index in a 600 port chassis is a pleasure that only a select few seem to appreciate, myself excluded.

OID	1.3.6.1.4.1.25506.2.66.3.6.1
Original description	A flux which used to overflow its upper limit, falls below its lower limit "$3" on a port(Index:$c) of Device "$R($a)". Trap type is $2. The port status is $4.
New description	STORM-CONSTRAIN: $2(Broadcast:1,Multicast:2,Unicast:3) storm rising on port $c of device "$R($a)". Port status is $4(controlled:1,normal:2).
Comment	Lets use the parameter switch with parenthesis which the falling trap below base description was making us of. Here again, I wish HP reported ifDescr as a parameter for this trap. Or we could have a function in IMC which returns ifDescr (Gig4/0/34) from the index (167, arbitrary example of the kind of madness you get trying to locate what the hell is port 167 in your 10 slot 7500).