Email alert not working and Alert Details

Hi rastanz,

Yeah, known issue.  We put in a fix for the release that will come out in Q1.  You may review those other threads you mentioned again.  There might be a (unpleasant) workaround where you install a local SMTP server on the OME box.  The problem is related to account permissions in the sending of emails.  And a local SMTP server solves this in the meantime.  But yeah, fixed in the new version.

On the alert, take a look at FAQ #10.1 and see if it may be the same.

Thanks,

Rob

Uncheck Send Authentication Trap in the SNMP setting on the Security tab.

Sorry for digging this old thread.

I get the "0.0.0.0 - authentication failure" traps (5 each days) and unable to determine where they come from. How can I do ?

I've checked the iDrac (6 and 7) of my  servers  and can't find that "security" tab.

I've 14 servers, 3 switch stack and 3 equallogic storage.

Hi there,

Can you review FAQ #10.2 and see if it might apply?

Regards,

Rob

delltechcenter.com/ome

en.community.dell.com/.../3265.openmanage-essentials-faq

Hi,

I have some iDrac 6 / 1.85 and iDrac 7 / 1.56

everthing is fine except a handful of daily SNMP traps from 0.0.0.0...

Hi,

Do you have few devices in OME device tree classified as "Unknown"? Since you are receiving authentication failure traps, that means OME is trying to connect to targets with wrong SNMP community string. Also, since you are receiving these alerts on daily basis approximately at same time, the trigger point is OME's scheduled discovery/inventory/status polling. Once you are able to locate those devices and configure matching SNMP community string (at the device as well as OME's discovery range configuration), you won't receive authentication failure traps any more.

For the second point where source is determined as 0.0.0.0, OME's latest released version 2.0.1 addresses this. This is generally a failure of the agent not able to set the source agent IP address properly in the SNMP trap PDU.

Do let us know if the information helps in rectifying the issue.

Seems like IPv6 addresses (collapsed) are set as source address in SNMP trap PDU. Please check if IPv4 is properly configured on these targets.

Thanks for updating the thread.

Hi,

Thanks you all for trying to help.

Apart from those alerts everything is fine.

Following the upgrade to OME 2.0.1 the incriminated alerts are now reported from 2002:a067:eb05::a067:eb05.

And some alerts (such as "limk up") from my powerconnects 6248 are now reported as coming from ::1

investigating....

We are not using ipv6 internaly whatsoever.

I've checked all tree PowerConnect stacks and confirm that ipv6 is disable globally.

snmp is set to send SNMPv2 traps from those.

So, the latter and recent ::1 unidentified source is a new problem.