Hi,
I can only share my experience on Fedora 20 where the trap daemon replaces the very first « .1 » by iso, So I had to:
JmonTH.pl: ### Fedora20 trap daemon sends the traps in the form : iso.3.6.1.6.3.1.1.4.1.0
JmonTH.pl: ### Substitute Starting iso by 1
JmonTH.pl: $line =~s/iso\./\.1\./g;
In the trap handler
May help.
Best regards
JMJ
De : Brian Kejser [mailto:***@kaiserdigital.com]
Envoyé : lundi, 26. janvier 2015 21:47
à : net-snmp-***@lists.sourceforge.net
Objet : RE: SNMP traps and unknown log file
Thanks
#
#
#
EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT Device reinitialized (coldStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (coldStart)"
SDESC
A coldStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself and that its
configuration may have been altered.
EDESC
#
#
#
EVENT warmStart .1.3.6.1.6.3.1.1.5.2 "Status Events" Normal
FORMAT Device reinitialized (warmStart)
#EXEC qpage -f TRAP notifygroup1 "Device reinitialized (warmStart)"
SDESC
A warmStart trap signifies that the SNMPv2 entity, acting
in an agent role, is reinitializing itself such that its
configuration is unaltered.
EDESC
#
#
#
EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" Normal
FORMAT Link down on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link down on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.
EDESC
#
#
#
EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" Normal
FORMAT Link up on interface $1. Admin state: $2. Operational state: $3
#EXEC qpage -f TRAP notifygroup1 "Link up on interface $1. Admin state: $2. Operational state: $3"
SDESC
A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus.
EDESC
#
#
#
EVENT authenticationFailure .1.3.6.1.6.3.1.1.5.5 "Status Events" Normal
FORMAT SNMP athentication failure
#EXEC qpage -f TRAP notifygroup1 "SNMP authentication failure"
SDESC
An authenticationFailure trap signifies that the SNMPv2
entity, acting in an agent role, has received a protocol
message that is not properly authenticated. While all
implementations of the SNMPv2 must be capable of generating
this trap, the snmpEnableAuthenTraps object indicates
whether this trap will be generated.
EDESC
From: Aly Khimji [mailto:***@gmail.com]
Sent: Monday, January 26, 2015 12:16 PM
To: net-snmp-***@lists.sourceforge.net<mailto:net-snmp-***@lists.sourceforge.net>
Subject: Re: SNMP traps and unknown log file
Hey,
Can you show the contents of your snmptt.conf file?
From my experience I have found that anything the snmptt can't understand (eg doesn't have a definition for it will log as unknown).
For that reason I have a catch all in my config as the very bottom of that config file. (see below)
Example of a catchall in mine
EVENT CatchAll .1.* "snmptt catchall" Critical
FORMAT $D
EXEC /usr/lib64/nagios/plugins/eventhandlers/submit_check_result "$r" "TRAP" 2 "$O: $1 $2 $3 $4 $5"
SDESC
This is the catch all snmptt MIB definition. This means that this trap does not have a MIB definition in snmptt.conf on the server.
EDESC
Aly
On Mon, Jan 26, 2015 at 2:57 PM, Brian Kejser <***@kaiserdigital.com<mailto:***@kaiserdigital.com>> wrote:
Hi
Iâve done the following.
- Ubuntu Server 14.04.1
- Installed snmp, snmpd and snmp-mibs-downloader
- Downloaded and unpacked Dell MIBS to the folder /usr/share/snmp/mibs
- Deleted the file /usr/share/mibs/ietf/IPSEC-SPD-MIB
- Deleted the file /usr/share/mibs/ietf/IPATM-IPMC-MIB
- Deleted the file /usr/share/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB
- Deleted the file /usr/share/mibs/ietf/SNMPv2-PDU
Edited the file /etc/default/snmp.conf
mibs +ALL
Edited the file /etc/default/snmpd
TRAPDRUN=yes
Edited the file /etc/snmp/snmptrapd.conf
authCommunity log,execute,net public
traphandle default /usr/sbin/snmptt
ignoreauthfailure 1
disableAuthorization yes
Edited the file /etc/snmp/snmptt.ini
date_time_format = %H:%M:%S %Y/%m/%d
log_system_enable = 1
unknown_trap_log_enable = 1
When a trap is received, it ends up in the unknown trap log file. I am able to use snmptranslate to translate the MIBs in the unknown trap log file. Why are all SNMP traps being treated as unknown when snmptranslate can translate them?
Thanks
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-***@lists.sourceforge.net<mailto:Net-snmp-***@lists.sourceforge.net>
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users