Conference azur::mcc

Bj�rn,

	Thank you for pointing this out.  This seems to be a limitation of
the alarms fm.

	I've entered a qar (number 2435) in the mcc_internal qar database.

	At present there are two ways to obtain the argument info you're
interested in.  Use the getevent directive from FCL (not very helpful) or
use Notification.  Notification services will return this info.  I've included
an example below (using a chipcom hub) using fcl.  This info should also be 
available via Notification when running the Iconic Map PM.  I seem to remember
that this didn't work with the T1.2.4 kit, so you'll need the later version.



	Dan

================================================================================

MCC> enable  mcc 0 alarm rule snmp_linkdown ,in domain d

MCC 0 ALARMS RULE snmp_linkdown
AT  4-MAR-1992 16:15:46

Normal operation has begun.
MCC> notify domain d
%MCC-S-NOTIFSTART, Notify request 1 started
MCC>
!!!!!!!!!!!!!! Alarm,  4-MAR-1992 16:20:14 !!!!!!!!!!!!!! [1]
Domain: ETHRFX_NS:.d                                  Severity: Warning
Notification Entity: SNMP ETHRFX_NS:.chip
Event Source: Domain ETHRFX_NS:.d Rule snmp_linkdown
Event: OSI Rule Fired

                             Event Type = QualityofServiceAlarm
                             Event Time =  4-MAR-1992 16:20:11.36
                         Probable Cause = DegradedSignal
                        Additional Info = { (
                               significance = True,
                                information = "The last event detected: SNMP
                                              ETHRFX_NS:.chip linkDown
                                              4-MAR-1992 16:20:10.11" ),
                                            (
                               significance = True,
                                information = "Event: linkDown A linkDown trap
                                              was received:  enterprise =
                                              ""1.3.6.1.4.1.49.1.3.1.0""
                                              agent-addr = 16.126.16.124
                                              generic-trap = linkDown
                                              specific-trap = 0  time-stamp =
                                              363312565  ifIndex = 179" ),
                                            (
                               significance = True,
                                information = "(OCCURS (snmp * linkdown))
                                              " ) }
                         Managed Object = SNMP ETHRFX_NS:.chip
                     Perceived Severity = Warning
                        Additional Text = "Linkdown Trap has occurred
                                          "

MCC> terminate notify *

notify request 1 terminated by user request
MCC> 
MCC> disable mcc 0 alarm rule snmp_linkdown,in domain d

MCC 0 ALARMS RULE snmp_linkdown
AT  4-MAR-1992 16:33:45

Normal operation will be terminated.
MCC>                                                                               

Thank you for a very helpful answer. This looks great!!!

My problem was to actually test for an event on a specific INTERFACE.
Is this a limitation on the TRAP function in SNMP, I mean, the SNMP xxx entity 
is reporting the trap, not the SNMP xxx INTERFACE yyyy. This means I have to
use Notification to get the information needed to find the reason.

I tried to define an alarm using SNMP xxx INTERFACE yyy event linkDown, but it
won't accept other than SNMP yyy event linkDown. I'm not so sure this is a 
limitation of the Alarms FM, since it seems that it is the global SNMP entity 
that sends the trap. In NODE4 you can test for events from the interface level.

I'm only trying to understand the behaviour.

Bj�rn Olav

RE: 2479.2

Yes, the linkDown event is returned for the SNMP entity, not for one
of its children.

Note that the actual interface that went down is indicated by the event
argument IfIndex.

Bj�rn,

	Part of the problem is a limitation of the alarms fm, that is,
you cannot alarm on arguments returned as part of event reports.  In general
you can't define an alarm rule that includes a complex expression.  Alarms
needs to provide support for rule expressions something like the following,

	expression = (occurs (snmp * linkdown) && (ifIndex = 1))

	This says fire the alarm when a linkdown event is reported and the 
ifIndex argument is equal to 1.  

	We could consider making the linkdown event an interface child entity
event instead of an snmp global entity event.  This would solve the problem
for the linkdown trap. But, let's say you wanted to alarm on a specific
enterpriseSpecific trap, the specific trap number is also an event argument.
It's not unreasonable to expect that one would be able to define an alarm
rule that would fire only for a specific enterpriseSpecific trap.  

	The unfortunate fact is, until this capability is provided by the 
alarms fm, alarming on snmp traps/events will be rather limited.

Dan

    In fact, for enterpriseSpecific traps, its value is limited.  When will
    the alarms fm be able to provide this capability?
    
    -Dan H.