Unsolved
This post is more than 5 years old
4 Posts
0
150577
August 20th, 2013 04:00
Not seeing SNMP traps in OpenManage Essentials
I'm trying to monitor SNMP traps with OpenManage essentials, and currently not seeing any of the traps generating alerts.
Monitoring my incoming SNMP traffic with Wireshark I can see SNMP traps arriving at my OME server, but going into the Dell troubleshooting Tool, and using the Windows SNMP Trap Listener I do not see any trap arriving.
Looking at the port availability in the Dell Troubleshooting Tool, I have two "Process holding UDP 162 port"; both entitled 'snmptrap'.
Stopping the windows SNMP trap serivce, and trying the 'Net SNMP Trap Listener' in the Dell Troubleshooting tool I do see traps arriving at my OME server, with messages like 'Info: SNMP v1 Trap Received... [Other Info].'
Any ideas why the Windows SNMP Trap listener seems not to like these traps? I assume it is neccessary for it to see these before anything can possibly appear in OpenManage Essentials?
0 events found


DELL-Pupul M
2 Intern
•
1K Posts
0
August 20th, 2013 04:00
Hi Neil,
It is important for OME that the port 162 is dedicated for OME. If any other tool is using that port then OME will not be able to process those to the database. This link may be of some help to you. en.community.dell.com/.../20423736.aspx
NeilTarrant
4 Posts
0
August 20th, 2013 05:00
Hi,
Sorry, I don't follow the relevance of your link there.
Should I not see snmptrap listening on port 162? I was under the impression that this was the windows services which Dell OME used to access/receive incoming SNMP traps? Am I mistaken? Is there another process name I should expect to see listening on port 162 when Dell OME is working correctly?
Regards,
Neil
DELL-Pupul M
2 Intern
•
1K Posts
0
August 20th, 2013 06:00
Hi Neil,
I should have been more clear. Let me restate:
Is there any other application along with OME installed on the system which is using the 162 port? When you use Troubleshooting tool to verify the port state and if OME is the only application installed, then only it means OME is using this port. So, i wanted to ask is their any other application other that OME which is using that port?
NeilTarrant
4 Posts
0
August 20th, 2013 06:00
The only processes which the troubleshooting tool reports are using port 162 are two processes called 'snmptrap' - is that the correct process for the Dell OME?
DELL-Rob C
4 Apprentice
•
2.8K Posts
0
August 20th, 2013 12:00
yeah, so Pupul is just suggesting to run netstat -a or similar to ensure that nothing else is using 162. If some other app like wireshark is using it, it would block reception and you would not see them in OME.
What devices are you trying to get traps for? Your PowerEdge servers? Or some other device?
Thx
Rob
MattiasZ
52 Posts
0
September 7th, 2015 03:00
Hi.
Did you ever get this resolved? I got the exakt same problem.
When i start the troubleshooting tool and active snmp trap listener i can see traps coming. But nothing is showed in openmanage essentials. In netstat is only shows this no more 162 ports:
UDP [::]:162 *:*
NeilTarrant
4 Posts
0
September 7th, 2015 03:00
I seem to recall that the relevant port wasn't open through the windows firewall, so traffic was being blocked at a level above that which packet-capture was monitoring.
I may be mistaken, but hopefully this gives you something to look at.
Neil
DELL-Shivendra K
2 Intern
•
685 Posts
1
September 7th, 2015 03:00
Hi, thanks for the query.
I would suggest you to restart SNMP trap service and then restart all OME services from the console. The traps in OME may stop working if the binding with dependent SNMP trap service is lost.
Do let us know of the results.
MattiasZ
52 Posts
1
September 7th, 2015 04:00
Hi.
Restart of every openmanage essentials service solved the case, now i can recive traps.
Thanks for the info from everybody!
SSJ1137Gokeu
10 Posts
0
October 15th, 2015 20:00
Hi Shivendra K,
I'm also experiencing the same issue where OME will intermittently stop displaying SNMP traps, but will still receive them based on the Dell Troubleshooting Tool. Restarting all OME services from the console does help, but I'm often doing this 2 or 3 times a week.
You mention that "The traps in OME may stop working if the binding with dependent SNMP trap service is lost." Could you clarify on this? Is there a way to verifying if this is happening on my end?
BR,
SSJ1137GOKEU
SSJ1137Gokeu
10 Posts
0
October 16th, 2015 11:00
Thanks for clarifying. I've examine the windows application log and there does't appear to be any error.
OME and Repository manager are the only application installed on the server. I also ran a test stated in the previous post and I get the same result: UDP [::]:162 *:*
DELL-Shivendra K
2 Intern
•
685 Posts
0
October 16th, 2015 11:00
Hi,
One way would be to analyse Windows applications logs. Observe if the SNMP trap service is registering any failures and getting restarted time to time.
Also, are you using any other NMS on the same box where OME is installed? Generally, it is recommended to have one monitoring tool on one system which helps in avoiding any port related conflicts and achieving smooth operations.
DELL-Shivendra K
2 Intern
•
685 Posts
0
October 16th, 2015 12:00
Hi,
I am running out of suggestions at this point. However, I would request you to open a support ticket on 800-945-3355. This will help our engineer to take a deeper look and possibly rectify your problem once and for all.
agw1
1 Message
0
October 26th, 2015 11:00
I'm also having the same problem after I upgraded from OME 2.0.1. I see the trap events from the OME troubleshooting tool. After restarting all the OME service, it'll work for a a day. I'll probably open an incident on this.
SSJ1137Gokeu
10 Posts
0
November 16th, 2015 21:00
Hi AGW1,
Not sure if you are still experiencing the problem, but a reinstall of OME might fix the issue. The issue has not resurface for about two weeks after I reinstall OME. Hopefully that helps fixes your issue.
Cheers!