10-22-2012 05:37 AM - edited 10-22-2012 05:43 AM
We are integrating NNM 9i( 9.10 ) with OMU server and we need to generate SNMP traps using nnmsnmpnotify command.
When I look at OM template which forwards NNM events to OM as in attached image and I ran
nnmsnmpnotify.ovpl -v 2c -c public -a au336 -e .184.108.40.206.220.127.116.11.17.19.2 au336 .18.104.22.168.22.214.171.124.126.96.36.1990
but it is not generating any incidents in NNM.
Require help in forming correct nnnsnmpnotify command please...
Solved! Go to Solution.
10-22-2012 10:52 AM
I'm using this format to generate events:
nnmsnmpnotify.ovpl -v2c -d -a <IP address of the node> <IP address of the server> <oid>
For node down event, use OID: .188.8.131.52.184.108.40.206.220.127.116.11.32
10-23-2012 02:31 AM
Thanks for your response Paulo.
I tried to run following commands,
/opt/OV/bin/nnmsnmpnotify.ovpl -v2c -d -a sourcenodeip NNMServerIP .18.104.22.168.22.214.171.124.126.96.36.199.32
/opt/OV/bin/nnmsnmpnotify.ovpl -v2c -d -a sourcenodeip NNMServerIP .188.8.131.52.184.108.40.206.220.127.116.11.70
for nodeDown and SNMP Agent not responding traps, but I am not seeing any incidents in NNM console...
Also I am not able to see any entries in log files under /var/opt/OV/log/nnm directory.
Is there any way I can trace or look at other log files...
10-23-2012 07:06 AM
you need to have enabled and configured these incidents and the device which is sending the traps. You have to check it first.
Once it has been checked, I think that you need to be sure that the traps are arriving to the NNMi server and if yes, you need to check if NNMi is discarding them by any reason.
To check if the traps sent by the device are not being blocked by NNMi because the the device is not correctly being monitored, you need to check:
- #nnmtrapconfig.ovpl –dumpBlockList
- The file nnmtrapd.conf.
Once you have checked that both the incident is enabled and configured and the device is correctly being monitored, you can enable tracing for the events subsystem and check the log files generated.
To enable the tracing FINEST for the com.hp.nms.events and for the nms.trapd:
- #nnmsetlogginglevel.ovpl com.hp.ov.nms.events FINEST
- #nnmsetlogginglevel.ovpl com.hp.ov.nms.trapd FINEST
- #nnmtrapdump.ovpl –last 5 –t
- Force the device to send a trap to NNMi.
After that, disable the tracing:
- #nnmsetlogginglevel.ovpl com.hp.ov.nms.events CONFIG
#nnmsetlogginglevel.ovpl com.hp.ov.nms.trapd CONFIG
There, you can see what is happening with the traps when they arrive to the NNMi. You can open a support case to investigate it in detail.
Hope it helps
10-30-2012 02:52 AM
Thanks for your detailed help.
Problem was with the trap OID was in blocked list so I ran nnmsnmpnotify.ovpl with allowed trap OID and now I see NNMi incident been created.
I checked /var/opt/OV/shared/nnm/conf/nnmtrapd.conf and found there is no blocking specified in the file..
Can you please help me how can I remove blocking for certain trap OID?
11-09-2012 09:55 AM - edited 11-09-2012 09:56 AM
An excerpt from the NNMi 9.20 Deployment Reference:
Blocking Incidents using the trapFilter.conf File
Suppose the number of incidents flowing through your NNMi management server reaches a rate that causes NNMi to block newly arriving incidents.
When this happens, NNMi generates a TrapStorm incident, indicating that incidents are blocked. NNMi might also generate a major health message indicating that the incident rate is high and incidents are being blocked.
To remedy this, you might try to use the nnmtrapd.conf file to block incidents from entering NNMi in an attempt to reduce the incident traffic. However, if you use the nnmtrapd.conf file approach, NNMi still uses these incidents to calculate the trap rate and to write to the trap binary store. By using the nnmtrapd.conf file approach, you only stop incidents from being created or stored in the database. See the nnmtrapd.conf reference page, or the UNIX manpage for more information.
There is a better solution to this problem than using the nnmtrapd.conf file. NNMi provides a filtering mechanism that blocks incidents earlier in the NNMi event pipeline, preventing these incidents from being analyzed for trap rate calculations or from being stored in the NNMi trap binary store. By adding device IP addresses or OIDs to the trapFilter.conf file, you can block these high-volume incidents and avoid incident volume problems. See the trapFilter.conf reference page, or the UNIX
manpage for more information.
If you have just started off with using NNMi 9.20, this link might help you in getting most common info you will need:
HP Software Support
The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of HP.
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution.
11-11-2012 08:53 PM
Thanks everyone for your contribution.
There was no problem with blocking the traps.
Once I took a trace I found out the trap was been received and getting processed.
The problem was the trap was not resolving to any source object node component within the device.
Once I went to Configuration->Incidents->Incident configuration and unchecked "Discard Unresolved SNMP Traps and Syslog Messages" the traps got processed and NNM incidents got created.
Thanks for everyone's help..