Can we correlate the AM-Domain polled events and the SNMP Traps?

By referring to various documents and discussing with some friends I can see that, it is possible to forward the following traps to IP Manager.

1. Link up/down

2. cold/warm start traps

3. hsrp traps

4. module up/down traps.

This can be done by by configuring the port as I mentioned in my above message.

But could someone please help me, to understand, how we can process these traps that are received on the AM-Domain?

How can we correlate these traps with teh AM-Domain polled events?

Thanks

Arun

Thanks Fred.

But could you please advice whether is it possible to correlate these traps with AM-Polled events?

Thanks

Arun

Hi Berkay,

Thanks a lot.

I acme to know that, in NPM module, they can correlate the SNMP Traps and Syslogs, which they receive on NPM (whether it is BGP or OSPF) and correlate them with the polled alerts that are generated by the BGP or OSPF servers.

Being honest, I am 100% sure how this works.

So this led me to think of correlating the traps and the polled events on AM-Domain servers. Because, in my environment, the users doesnt want to supress the traps, that are received through trap-adapter->OI server-SAM server. Users are interested in both the polled events and these unsolicited traps.

Because they dont want to miss any event or any issues by any means.

So only option to reduce the number of alerts on SAM Notification console, is to correlate the similar notifications.

For exampls, if we get a Interface Down alert from a device called 'ABC', and for the same issue, we will get link down traps from the same device. So is it possible to correlate these alerts together? Or any other method that you can think for reducing these alerts rather than suppressing them?

In my environment, we got

1) cold/warm start enabled

2) hsrp traps enabled

3) link up/down traps enabled

4) module card inserted/removed etc traps enabled

Along with all these traps, I do have polled events from the AM Domain servers.

Hope this clears my situation.

Thanks

Arun

Hi Arun,

Good news is that AM domain already does what you're trying to do . Just like NPM, AM domain also uses some traps for correlation including link up/down, cold/warm starts, etc. You can take a look at the trapd.conf file under IP to see the list of traps AM requires. Your trap processing should be configured (if not already) to forward these traps to the AM domains.

The confusion arises from the fact that Smarts (unlike other solutions in the market) does not show these traps explicitly as events. It uses them as instrumentation for symptoms. Smarts does not correlate events or poll results. These results are mapped to symptoms and then symptoms get correlated. This is a different concept that takes some getting used to, and i may not have done a good job in explaining.

For any snmp traps that are not used by AM but you think that they are still important, the typical method is to use the snmp trap adapter to create notifications. Having these correlated with AM events is very complex and IMHO not feasible. Once you have these traps, I'd suggest you look into rules based correlation using hook scripts, escalations, etc.

Hope this helps.

Regards,
Berkay Mollamustafaoglu
http://www.ifountain.com
Ph: +1 (571) 766-6292
mberkay on yahoo, google and skype

Great. Thanks a lot Berkay. Understood.

Regards

Arun

There is actually another alternative that can be considered that is a little tricker to accomplish, but let me first reiterate that per the comments the SNMP traps are typically presented in the SMART Adapter Platform and consumed by AM (with the context lost).  As a result, linking between the two is not typically done.

More than a year ago, I posted a thread about Aggregate Notifictions (https://community.emc.com/docs/DOC-1212).  This is a powerful feature of SAM that can be used to accomplish your goal.  By wrapping the SNMP Traps (from the SMART Adapter platform) into an aggregate that has the same class, instance, and event name as a symptomatic event in AM explained by the root-cause you can link the two in the SAM console.

To get a list of the events explained by a particular root-cause, pick one that is active and run a simple ASL script:

default class="Router";
default instance="network:151.164.44.1";
default event="Down";

START {
} do {
   print("The problem ".class."::".instance."::".event);
   print("explains       ".getExplains(class,instance,event))?LOG,IGNORE;
   stop();
}

Note: In the IP product we restrict the output when the problem isn't active.  This saves us lots of excess computation.  For your test, pick one that is active.

The key points here:

1. The aggregate needs to exist in SAM *prior* to the root-cause being presented. 

Note: With the correlation interval at 30 seconds and a 65 second smoothing interval, and no smoothing between OI and SAM, it would be very hard to not get it into SAM first.

2.  The aggregate needs to have the exact same triplet (class, instance, event) as the event from IP

3.  The event from AM doesn't need to be sent to SAM - just being in the explanation tree is enough.

The way it works is that when the root cause arrives in SAM, SAM calls back to AM to get the explanation tree.  It will then convert the event names to object references and look for those objects in SAM.  If the event object exists, we will establish a Causes/CausedBy relationship between the two regardless of the source.

Thanks William

Regards

Arun