I recently reinstalled UDT upgraded to 3.4 to attempt to meet a use case requirement where we want to know when a new MAC address appears on a specific device type. I used the canned alert "Alert me when a new MAC address appears on network" as the template and changed it up to use a Primary and Secondary Section. On the primary I used the Node object and on the Secondary I used the "New MAC Address" object. This allowed me to limit the device type but, the alert email action does not have the variables available to provide the pertinent MAC information to provide for a meaningful alert email without several custom SQL/SWQL calls. Not a big deal but, I'm just not a fan except in very special cases. I also inverted this selection as another test but, I'm finding that the alerts reports other device types as well.
Another option I tried was to set the Trigger condition based on a Custom SWQL against the "New MAC Address" object. This is the only one that seems to actually suppress the other object types.
SELECT NewMACAlert.Uri, NewMACAlert.DisplayName FROM Orion.UDT.NewMACAlert AS NewMACAlert
JOIN Orion.Nodes N ON NewMACAlert.DeviceID = N.NodeID
WHERE N.Vendor = 'Meraki Networks, Inc.'
This allowed me to get many of the needed MAC attributes in the alert but, not the port name or any of the Node attributes...like which switch is this occurring on. Again , I employed a custom SQL/SWQL joining the two tables.
Consider that all of the Meraki devices have been discovered in my environment for over a year, and UDT has been installed now for over 30 days.
These are the issues I'm having with any approach:
The only thing that seems to work to limit the scope to a specific vendor is the Custom SWQL trigger
Why is there a Port ID = -1 in the NewMACAlert
At a 1 minute "Evaluate the trigger condition" I'm getting flooded with emails.
How long is something New?
What exactly constitutes New
Why do I get duplicate alert emails every minute?
Why/How can I have more then one MAC on a port with the same last seen time?
Many times the email comes back and instead of the value that should have been retrieved from the custom SWQL, the query itself is returned