SNMP integration

[jenstar13]

Hi,
we have SNMP running and going to a machine already
we are trying to get XI to accept the traps and show it in the interface
our engineer has asked me to ask this question

“why do relayed traps show up under the relayed host and not the snmp agent machine that actually generated the trap and has the problem?”
We have an existing system that receives traps for systems and it is forwarding those traps to XI via snmptrapd.conf “forward”
The snmptt logs on the XI box show the trap as coming from the agent box, but they show up in XI as coming from the relay box.


thank you in advance

[cdienger]

I belive this behavir is a result of passing the handler $r. Try chaning it to use $aA instead. For example:

EXEC /usr/local/bin/snmptraphandling.py "$r" "SNMP Traps" "$s" "$@" "$-*" "Link down on interface $1. Admin state: $2. Operational state: $3"

to:

EXEC /usr/local/bin/snmptraphandling.py "$aA" "SNMP Traps" "$s" "$@" "$-*" "Link down on interface $1. Admin state: $2. Operational state: $3"

Variables and their meanings can be found at:

http://snmptt.sourceforge.net/docs/snmp ... stitutions

Make sure to restart snmptt and and snmptrapd after making any changes:
service snmptt restart
service snmptrapd restart

[jenstar13]

have a response from my System Engineer

Response:

“$A” and “$aA” both work… is XI doing the dns resolution when the handler just uses the IP address $aA?
Where would we update the code so that new addmib/snmpttconvertmib runs add the proper “$aA” to the EXEC line vs the default? We have over 500 lines to edit now and it will just keep growing…

Thank you,

[jenstar13]

more questions

What’s the difference between the snmptt.conf file with addmib and the processed mibs directory?
We noticed that the conf has this, for example:

MIB: CPQRACK-MIB (file:/usr/share/snmp/mibs/cpqrack.mib) converted on Mon Apr 30 13:00:59 2018 using snmpttconvertmib v1.3
#
#
#
EVENT cpqRackNameChanged .1.3.6.1.4.1.232.0.22001 "Status Events" INFORMATIONAL
FORMAT Rack name changed (22001): The rack name has changed to $3.
EXEC /usr/local/bin/snmptraphandling.py "$aA" "SNMP Traps" "$s" "$@" "$-*" "Rack name changed (22001): The rack name has changed to $3."
SDESC
Rack name has changed.
This trap signifies that an agent or utility has changed the name
of the rack. Each of the server blades in each of the enclosure


But the smptt system log also say it loads this file (same contents): /usr/share/snmp/mibs/processed_mibs/cpqrack.txt but there is no EXEC in there

MIB: CPQRACK-MIB (file:/usr/share/snmp/mibs/cpqrack.mib) converted on Fri Jul 27 07:24:13 2018 using snmpttconvertmib v1.3
#
#
#
EVENT cpqRackNameChanged .1.3.6.1.4.1.232.0.22001 "Status Events" INFORMATIONAL
FORMAT Rack name changed (22001): The rack name has changed to $3.
SDESC
Rack name has changed.
This trap signifies that an agent or utility has changed the name
of the rack. Each of the server blades in each of the enclosure


We are confused how they got into processed and which one we are supposed to use…

[cdienger]

dns resolution is controlled by the snmptt.ini file with the line:

dns_enable = 1

http://snmptt.sourceforge.net/docs/snmptt.shtml#DNS has some more information regarding the setting.

/usr/local/bin/addmib is a script that adds entries to the snmptt.conf. Line 33 controls the EXEC line that gets added.

You should be working with the entries in snmptt.conf - the files in processed_mibs are there from when they initially went through the system and didn't have an entry in snmptt.conf

https://support.nagios.com/kb/article.php?id=73 goes through the flow of how MIBs get added.