Unsolved

This post is more than 5 years old

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?

2 Intern

 • 

1K Posts

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

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

2 Intern

 • 

1K Posts

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?

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?

4 Apprentice

 • 

2.8K Posts

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

52 Posts

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               *:*

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

2 Intern

 • 

685 Posts

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.

52 Posts

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!

10 Posts

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

10 Posts

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               *:*

2 Intern

 • 

685 Posts

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.

2 Intern

 • 

685 Posts

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.

1 Message

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.

10 Posts

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! 

0 events found

No Events found!

Top