Page 1 of 2
Snmp issue
Posted: Tue Jun 10, 2014 2:55 am
by lannister
Im trying to send snmp traps from the EMC host, how i can confirm that nagios is receiving or not receiving those trap.
Or least to know what error is it throwing.
Because I have configured the EMC host to send the traps to nagios.
This is the outcome on nagios
SNMP TrapsPassive Only Check Ok 11h 39m 45s 1/1 2014-06-01 19:26:13 Waiting for trap...
I have also added the MIB of clariion on nagios, the snmp is also enabled on my vnx
.
Update so far -:
And I have also checked for Admin unconfigured objects , it says no unconfigured objects.
When i did tail the out put i got is as follows -: 05:53:47 2014 .1.3.6.1.4.1.1981.0.3 Normal "Status Events" 1**.**.***.** - An Informational EventMonitorTrap is generated in SPB 2002 This confirms that events will be sent from the storage system to the destination you specified. N/A
I downloaded a MIB for clarion and installed it on nagios but im supposing MIB are supposed to be installed on Storage ?
root@localhost ~]# tail -n 20 /var/log/snmptt/snmpttsystem.log
Mon Jun 2 04:15:52 2014 SNMPTT v1.4beta2 started
Mon Jun 2 04:15:52 2014 Loading /etc/snmp/snmptt.conf
Mon Jun 2 04:15:52 2014 Finished loading 64 lines from /etc/snmp/snmptt.conf
Mon Jun 2 04:15:52 2014 Changing to UID: snmptt (497)
Mon Jun 2 05:37:53 2014 SNMPTT v1.4beta2 started
Mon Jun 2 05:37:54 2014 Loading /usr/share/snmp/mibs/processed_mibs/clariion.txt
Mon Jun 2 05:37:54 2014 Finished loading 85 lines from /usr/share/snmp/mibs/processed_mibs/clariion.txt
Mon Jun 2 05:37:54 2014 Loading /etc/snmp/snmptt.conf
Mon Jun 2 05:37:54 2014 Finished loading 64 lines from /etc/snmp/snmptt.conf
Mon Jun 2 05:37:54 2014 Changing to UID: snmptt (497)
[root@localhost ~]# tail -n 20 /var/log/snmptt/snmptt.log
Mon Jun 2 05:53:47 2014 .1.3.6.1.4.1.1981.0.3 Normal "Status Events" 1xx.xx.xx - An Informational EventMonitorTrap is generated in SPB 2002 This confirms that events will be sent from the storage system to the destination you specified. N/A
Mon Jun 2 05:54:02 2014 .1.3.6.1.4.1.1981.0.3 Normal "Status Events" 1xx.xx.xx - An Informational EventMonitorTrap is generated in SPB 2002 This confirms that events will be sent from the storage sys
Please find the output of the both the commands that you have mentioned.
- Lan
Re: Snmp issue
Posted: Tue Jun 10, 2014 4:12 pm
by sreinhardt
Thanks for making a new thread. This looks pretty good, and your traps are coming in and being listed as known traps. Could you post /etc/snmp/snmptt.conf and we can look for the oid matching .1.3.6.1.4.1.1981.0.3. This way we can verify the EXEC line is proper and will send to nagios. Also currently it looks like your trap is being sent as IP not hostname, so when nagios receives that it will need a host with the ip address as the name, and a service called "snmp traps."
Re: Snmp issue
Posted: Wed Jun 18, 2014 1:43 pm
by lannister
Thanks for the reply and sorry for the late response I actually did not get any notification ,
The output i got was as follows-:
[root@localhost snmp]# tail -n 20 snmptt.conf
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
- Lan
Re: Snmp issue
Posted: Thu Jun 19, 2014 9:26 am
by slansing
We need to see a copy of snmptt.conf, not a tail, tails are generally used for log files due to their nature.
Re: Snmp issue
Posted: Fri Jun 20, 2014 12:45 am
by lannister
Hi ,
hope the below out put is what we are looking for -:
Code: Select all
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.
"snmptt.conf" 64L, 2303C
- Lan
Re: Snmp issue
Posted: Fri Jun 20, 2014 1:04 pm
by sreinhardt
This is the file we were looking for, but it seems to be lacking any non-default configurations. Could you also post your /etc/snmp/snmptt.ini please? If you could attach it, not paste it too, as they get rather large.
Re: Snmp issue
Posted: Mon Jun 23, 2014 10:42 am
by lannister
Hi ,
Please find the attachment.
- LAN
Re: Snmp issue
Posted: Mon Jun 23, 2014 11:27 am
by sreinhardt
Ah, it inserted it into a new file. Please post /usr/share/snmp/mibs/processed_mibs/clariion.txt
Re: Snmp issue
Posted: Wed Jun 25, 2014 10:28 am
by lannister
HI ,
Please find the output -:
Code: Select all
#
#
#
EVENT EventMonitorTrap .1.3.6.1.4.1.1981.0.2 "Status Events" Normal
FORMAT An EventMonitorTrap is generated in $*
SDESC
An EventMonitorTrap is generated in
response to a user-specified event.
Details can be found in Variables data.
Variables:
1: hostName
2: deviceID
3: eventID
4: eventText
5: storageSystem
EDESC
#
#
#
EVENT EventMonitorTrapInfo .1.3.6.1.4.1.1981.0.3 "Status Events" Normal
FORMAT An Informational EventMonitorTrap is generated in $*
SDESC
An Informational EventMonitorTrap is generated in
response to a user-specified event.
Details can be found in Variables data.
Variables:
1: hostName
2: deviceID
3: eventID
4: eventText
5: storageSystem
EDESC
#
#
#
EVENT EventMonitorTrapWarn .1.3.6.1.4.1.1981.0.4 "Status Events" Normal
FORMAT A Warning EventMonitorTrap is generated in $*
SDESC
A Warning EventMonitorTrap is generated in
response to a user-specified event.
Details can be found in Variables data.
Variables:
1: hostName
2: deviceID
3: eventID
4: eventText
5: storageSystem
EDESC
#
#
#
EVENT EventMonitorTrapError .1.3.6.1.4.1.1981.0.5 "Status Events" Normal
FORMAT An Error EventMonitorTrap is generated in $*
SDESC
An Error EventMonitorTrap is generated in
response to a user-specified event.
Details can be found in Variables data.
Variables:
1: hostName
2: deviceID
3: eventID
4: eventText
5: storageSystem
EDESC
#
#
#
EVENT EventMonitorTrapFault .1.3.6.1.4.1.1981.0.6 "Status Events" Normal
FORMAT A Fault EventMonitorTrap is generated in $*
SDESC
A Fault EventMonitorTrap is generated in
response to a user-specified event.
Details can be found in Variables data.
Variables:
1: hostName
2: deviceID
3: eventID
4: eventText
5: storageSystem
EDESC
- Lan
Re: Snmp issue
Posted: Wed Jun 25, 2014 10:59 am
by sreinhardt
It seems that you added the mib with snmpttconvert mib or something similar, as it is missing the exec line that will cause traps to be sent to nagios. I would suggest using the addmib command and adding it correctly.
You will need to:
Modify /etc/snmp/snmptt.ini and remove the /usr/share/snmp/mibs/processed_mibs/clariion.txt from the bottom.
rm -f /usr/share/snmp/mibs/processed_mibs/clariion.txt
addmib /usr/share/snmp/mibs/clariion*
If you could then upload the clariion.txt again from /usr/share/snmp/mibs/processed_mibs/clariion.txt hopefully it should be created correctly. If you do not have /usr/share/snmp/mibs/processed_mibs/clariion.txt send the /etc/snmp/snmptt.conf again as it would have been added there.