| Hi,
Using the built-in targeting, retargeting a notification to a different
entity can only be done if you can derive the correct target entity
based on either the entity that generates the event or on the event
itself. You do not get the capability to do anything complex like look
at the argument of an event, etc..
It sounds like in your case the event comes from the parent
entity and not the interface itself, and the same event arrives for
each different interface, so you'll have to use an alarm rule and the
data collector to do what you want.
I understand that the interface is specified somewhere in the details
of the event. In this case, you write an alarm rule which listens for
the event and runs a procedure which parses the event report to
determine which interface the event applies to. The procedure then
uses the data collector to generate an event, and specifies that the
target entity for that event is the correct entity (site XX, etc.).
You will need to set up a data collector entity in the correct domain,
and have a notify request running for that domain that listens for
events from the data collector. Finally, you may want to mask the
notification that will arrive whenever the rule fires by using filters
from the notification PM.
There are lots of examples in notes in here and in the MCC_TOOLS
conference on putting the data collector to work.
regards,
Pete
|
| It's a general hassle to decode these kinds of traps. Cisco and Vitalink
boxes do a generic 'link down' and 'link up' type of trap. If you write
an alarm rule that starts a batch job, these are the kinds of items
available to your batch procedure in P1 - P8:
P1 = "Domain LOCAL_NS:.soc Rule soc_SNMP_LINKUP "
P2 = "A link on a Vitalink or Cisco box has come back up"
P3 = "SNMP_LNKUP"
P4 = "(OCCURS (SNMP * linkUp))"
P5 = "13-JUL-1993 13:35:34.79"
P6 = "The last event detected: SNMP LOCAL_NS:.bbsoc3 linkUp
13-JUL-1993 13:35:33.88"
P7 = ""
P8 = "SYS$SCRATCH:MCC_ALARMS_DATA_13353479.DAT"
If you look at the values, you see that no interface information is
passed in any of the params. To get the interface number (which is what
you need to be able to figure out which link went down) you must
open and read through the file named in P8. It looks somthing like this
(this sample not from same trap as above):
RULE: Domain LOCAL_NS:.soc Rule soc_SNMP_LINKDOWN
MANAGED_OBJECT: SNMP health-ether
DESCRIPTION: A link on a Vitalink or Cisco box went down
CATEGORY: SNMP_LNKDN
EXPRESSION: (OCCURS (SNMP * linkDown), in domain soc)
TIME: 1-APR-1993 04:38:50.31
EVIDENCE: The last event detected: SNMP health-ether linkDown
1-APR-1993 04:36:42.59
EVENT_ARGUMENTS: Event: linkDown A linkDown trap was received:
enterprise = "1.3.6.1.4.1.9.1.5" agent-addr = 156.63.224.1 generic-trap
= linkDown specific-trap = 0 time-stamp = 112786675 ifIndex = 2 (
PARAMETER: _DKA700:[MCC]MCC_ALARMS_LOG_EXCEPTION.LOG
DOMAIN: Domain LOCAL_NS:.soc
SEVERITY: Critical
See the item "EVENT_ARGUMENTS:"? The portion of the line "ifIndex = 2"
is what is needed to figure out the link that caused the trap. As you
can guess, this takes some overhead to finally come up with the
number of the interface that caused the trap.
If anyone else has a better way to get the interface number from a trap
I'd appreciate knowing how.
Suggestion to MCC developers: Pass the "ifIndex = n" information
somewhere in one of the P1 - P8 parameters so that it is not necessary to
go through the hassle of opening/searching the MCC_ALARMS_DATA_xxxxxx.DAT
file.
Lee Roth
|