OME 2.0.1 trap forwarding problem

Hi Pupul,

Only software installed on OME server is OME (with all options - License Manager, Repository Manager, etc) and EQL SAN Headquarters. As I said - SNMP alerts are showing up fine from directly monitored devices, only forwarded ones are not showing in OME. Are those different in some way?

Ok, I have set community string in source OME. In destination OME there is nothing to be configured, it is just supposted to passively receive forwarded alerts?

Thanks,

Egils

Hi Egils,

SNMP community string is required to authenticate the alerts coming from a source. You will need to set the SNMP community string on the source OME.

Also, you mentioned that you are able to view the alerts in wireshark. So, just to be sure do you have any other program running on the same machine where OME is installed which would be using the same ports used by OME for SNMP alerts, which is port 162. 

Thanks for the details.

I have no further ideas to go around this issue. I have not seen the case when a properly configured setup does not get SNMP alerts or forwarded alerts in the console. Based on the detailed information that you have provided, it looks like your setup is correct. Firewall can sometimes be a problem, looks like not the case here. We will need a support ticket to take a closer look at the setup. Please call 800-945-3355.

Hi Egils,

OME depends on Windows SNMP Trap service for receiving alerts. If Windows SNMP service is not started or has be restarted after installation of OME, required binding will not happen or fail. As you mentioned that you are able to receive other traps directly from targets, I hope binding is not an issue here. Also, use "public" community name while configuring the trap forwarding action. Just to be on safer side, please follow the steps mentioned below and see if this help:

1. Make sure SNMP Trap service is started and the local system account (through which OME is also accessible) has log on access. If not, make required changes.

2. Restart OME services once above step is complete.

3. Configure forward trap action in secondary OME, on second screen of the wizard use "Test Trap" button and see if the primary OME received test trap. If the test trap did not go through, check firewall setting on both machines.

4. If #3 is successful, check if you have selected appropriate severity/category/device criteria to match concerned traps.

5. Test with actual traps.

SNMP trap service is running on both source and destination OME (otherwise I would not receive any SNMP alerts) with default settings. Both OME servers are freshly installed WS2012 with all updates. Have restarted OME services and servers many times. "Test trap" button on source OME behaves just like as desribed before - trap is not showing in OME or Troubleshooting tool on destination OME, but is showing in Wireshark capture, see screenshot. The same with a test trap from CMC.

In the screenshot first is forwarded test trap from OME using "test trap" button, second is test trap from CMC. Capture is done on destination OME.

Can you check if there is any alert ignore action created on the destination OME? Mostly if you are able to intercept the alert it should make entry to the database also. Also, check if any filters are there on the alert page so that you might not be able to see the alert in OME UI. Very basic thing, but sometimes it gets missed.

Checked ignore actions and filters, there are none that could affect this. Also that would not explain why the SNMP trap does not appear in Troubleshooting tool's SNMP listener. Right now it looks like in OME console and Troubleshooting tool I can see only SNMP traps originating in the local subnet where OME sits, traps from other subnets are not shown in OME and Troubleshooting tool, only in Wireshark capture. I even compared packets of the traps from local and remote subnets - they look the same, obvious differences aside.

Regarding Troubleshooting tool test, which trap listener did you chose to receive the alerts?

Windows SNMP Trap Listener depends on SNMP Trap service, behavior is expected to be same as OME for this option.

NetSNMP Trap Listener uses Windows independent API to receive traps. To use this option, stop SNMP Trap service then start the test in Troubleshooting tool. If WireShark is able to list the received SNMP packets, trap listener test in Troubleshooting tool should also be able to list them with this option.

Great. Thanks for letting us know.