Page 1 of 1

SNMPTT to Nagios

Posted: Wed Oct 23, 2013 7:53 am
by cellact
Hey,
I'm trying to configure SNMP Traps for a Cisco MIB.
The MIB contains OID's that integrate both Up/Down states.
Unfortunately I'm unable to understand how to set apart OK/Warning states accordingly.
The trap itself generates a number of variables, based on them I could potentially understand if the link is Up or Down.
I currently have in my snmptt.conf file:

Code: Select all

FORMAT SequenceNumber $1 : SourcePC $3 : AdjacentPC $4 : DisplayName $5 : LinkState $6 : LinkReason $7 : LinkTestResult $8
EXEC /usr/local/bin/snmptraphandling.py "$r" "Linkset Status" "$s" "$@" "" "$Fz"
Obviously the LinkState $6 variable represents Up/Down states:

Code: Select all

  6: cgspLinkState
     Syntax="INTEGER"
       1: available
       2: failed
       3: shutdown
       4: unavailable
Can I use this variable to decide on the Nagios service state that is passed on to the passive service?


Also, can I also use the "Variables" info that was converted from the MIB for the Format and Service Status data?
IE - Replace LinkReason $7 (which holds an integer) with it's data:

Code: Select all

  7: cgspLinkReason
     Syntax="INTEGER"
       0: unknown
       1: changeOverInProgress
       10: t3Timeout
       11: t6Timeout
       12: t7Timeout
       13: provingFailure
       14: protocolErrorBsn
       15: protocolErrorFib
       16: protocolErrorSin
       17: protocolErrorLssu
       18: peerNotReady
       19: communicationLost
       2: mgmtDisconnectRequest
       20: noListenPosted
       21: bufferNotAvailable
       22: cardRemoved
       23: cardInserted
       24: falseLinkCongestion
       25: configDownload
       26: localInhibit
       27: localUninhibit
       28: remoteInhibit
       29: remoteUninhibit
       3: linkAlignmentLost
       30: localBlocked
       31: localUnBlocked
       32: remoteBlocked
       33: remoteUnblocked
       34: linkRestored
       35: linkTestFailure
       4: connectionLost
       5: localDisconnect
       6: remoteDisconnect
       7: suermFailure
       8: t1Timeout
       9: t2Timeout
Thanks.

Re: SNMPTT to Nagios

Posted: Wed Oct 23, 2013 10:21 am
by cellact
I managed to load the MIBs using snmp.conf (had to create it at /etc/snmp/snmp.conf) and then I got the variable conversion working (ie 6 = remoteDisconnect)

Still trying to figure out if I can use the variables for the service state.

Re: SNMPTT to Nagios

Posted: Wed Oct 23, 2013 12:01 pm
by sreinhardt
This gets into some tricky stuff, but it is doable. If you could post the full snmptt.conf portion for this OID at least, I could give a much more clear example. However I believe that you will need to change the $s in your exec line, to $6 to get the cgspLinkState that is sent by your trap. Then, you will need to modify the snmptraphandling.py states that it understands to include 1: available, 2: failed, 3: shutdown, 4: unavailable, as varying states. Whether they are sent as the number or word I cannot say. With that modification, you will use each state to set the appropriate nagios state (0-3) as needed.

Re: SNMPTT to Nagios

Posted: Thu Oct 24, 2013 8:53 am
by cellact
Cheers!

I finally managed to get it to work (I guess what I'm doing is quite complex) by creating another snmptraphandling.py script and adding the relevant code

Code: Select all

    if severity == "available":
        return_code = "0"
    elif severity == "shutdown":
        return_code = "2"
    elif severity == "failed":
        return_code = "1"
    elif severity == "unavailable":
        return_code = "1"

Re: SNMPTT to Nagios

Posted: Thu Oct 24, 2013 10:26 am
by sreinhardt
That is exactly what I meant! Nice job! Creating a separate snmptraphandler is entirely up to you, but I can see where its beneficial if you update the package and it reverts your changes.

Re: SNMPTT to Nagios

Posted: Thu Oct 24, 2013 1:27 pm
by jwelch
That's what I was going to suggest.
I have had cases where I created a custom trap handler for snmptt to use. I let it pre-process
the trap and pass the results to the regular snmptraphandling.py script. That way I only have
to take care of the quirks of the particular trap in question and let snmptraphandling.py do the
rest.