Conference azur::mcc

    
    Al -
    
    Hi.  While I can not address the repitition aspect of the exception
    other than outside of MCC,  what I have been doing lately is the
    following:
    
    create domain somedomain rule mon_router1 -
    expression=(node4 router1 state = off), at every x,-
    parameter = somenode::someone
    
    assign target domain somedomain
    event source = domain somedomain rule mon_router1,-
    event name "OSI Rule Exception",-
    target entity = "Node4 router1",-
    target severity = critical
    
    create domain somedomain rule router1_up -
    expression=(change_of(domain somedomain rule mon_router1 result of last
    		evaluation, error, false), at every x),-
    parameter=somenode::someone
    
    assign target domain somedomain
    event source = domain somedomain rule router1_up,-
    event name "OSI Rule Fired",-
    target entity = "Node4 router1",-
    target severity = clear
    
    Out rules run every 00:05:00.  We keep a timestamp per rule name in a
    logical table with a slop factor of 1 minute and do not send mail if
    within the time frame.
    
    FWIW,
    
    Dave Comfort
    

    Hi Dave,
    
    thank for the recommendation.....I wasn't even aware that you could
    use a rule to fire another rule....clever!
    
    However, it is disappointing that we must use two rules to accomplish
    what should take a single rule.....and even at that, it should not
    require any programming on the part of the user.
    
    We definatetly need the ability to setup a rule that will react to the
    state UNREACHABLE in such a was as not to force external programming
    action.  I would assume that eventually the alarms will be fixed to
    allow one to determine the rule, the expression, a severity for each
    condition and to take action in the form of either or both an icon
    color change and/or a mail message.  
    
    I'm not saying we don't need the ability to fire an external command
    procedure or user writen program, but this should be an optional
    programming feature.  
    
    Today, there is simply too much work involved in getting MCC to do what
    it should do.
    
    Hopefull a QAR will escalate or get some answers.
    
    Al

RE: 4354.0  Al Licause

> I've been playing with the alarms rules most recently in T1.3 and can't
> seem to come up with a good combination that allows for a simple
> command procedure evaluation w/o having to use external flag mechanisms
> to avoid repetition of notification for the case of unreachable nodes.

    I see no short-term workaround for your problem. However...

    Have you had a chance to play with T1.3.0's IP Reachability Poller?

    Would supplying something similar for Node4 solve your problem?

						Chris 

Chris,

We have, what is right now, an OSI only network.  I"ll have to search around
for a SNMP device and see if I can play with it.  

I am running T1.3.

Any guess as to time frame for doing what was requested in .0?

Al

Chris,

I am using the SNMP poller and it is v good Something similiar for all global
entities would be great (not just phaseIV) as the reachability of bridges and
terminal servers is just as important from a network managers point of view.

An enhancement I would like to see to the poller, is an optional interface so 
that everytime the poller detects a reachability change, it can send the 
parameters not only to a Notification window, but also to a DCL procedure that 
sends mail, or executes a user written DCL command procedure. Yes I know that I
can write an Alarm routine for SNMP reachability and get the desired effect, but
just running the Poller makes it so much simpler to set up.

Ian

>An enhancement I would like to see to the poller, is an optional interface so 
>that everytime the poller detects a reachability change, it can send the 
>parameters not only to a Notification window, but also to a DCL procedure that 
>sends mail, or executes a user written DCL command procedure. Yes I know that I
>can write an Alarm routine for SNMP reachability and get the desired effect, but
>just running the Poller makes it so much simpler to set up.

Hi Ian,

I haven't played with the poller yet so I'm not sure if this applies. If the
poller is sending COLLECTOR events  then you can write an alarm rule on these
events:

exp=(occurs(collector * any event)) ....or something like this.

You can also creatively begin seperation by function using wildcards which
seems to work so far (unsure if supported)

exp=(occurs(collector .ip.* any event))  or
exp=(occurs(collector .node4.* any event))

Even if they aren't COLLECTOR events mcc *theory* says we should be able to 
alarm on them.

just a thought,
brad...

Hi Brad,

If the poller is sending Collector events then it is totally transparent to the
user. Can anyone from MCC Eng suggest a way of alarming on the IP poller 
generated events?

Ian 

The IP Poller is sending NOTIFICATION Events.

One should be able to write ALARMS on these, no?

					Chris

The IP Poller for T1.3.0 (EFT) sends CONFIGURATION Events. 

The IP Poller will send NOTIFICATION Events for EFT Update (T1.3.1).
This simplifies use of the poller (no notification setup for the poller
will be necessary for EFTU).

						Chris

>The IP Poller for T1.3.0 (EFT) sends CONFIGURATION Events. 

>The IP Poller will send NOTIFICATION Events for EFT Update (T1.3.1).
>This simplifies use of the poller (no notification setup for the poller
>will be necessary for EFTU).

So what would the expression look like???

exp=(occurs(mcc 0 alarms any notification event)   ???

brad...

>So what would the expression look like???
>
>exp=(occurs(mcc 0 alarms any notification event)   ???
>

  The first expressions that came to mind were:

	(occurs(snmp <instance|*> any notification event)

  or:	(occurs(snmp <instance|*> IP Reachability <Down|Up>)

  I'm told that wildcarding the <instance> for the above expressions
  is expensive (rule is domain based, so the wildcard is expanded
  and a thread is generated for each instance in the domain as of
  V1.3) but haven't verified it.

  I was also told that "If the rule is created from the fcl using
  the CREATE MCC 0 ALARM RULE format, without the IN DOMAIN NAME
  qualifier, then the wildcard is not supposed to be expanded
  by the alarms FM and it is supposed to be sent down to the AM."

  Hope this helps...

						Chris Brienen

Hi Chris,

Thanks for the info - I've created an alarm rule using 

>>  or:	(occurs(snmp <instance|*> IP Reachability <Down|Up>)

And it works fine.

Cheers

Ian

    Could you post the actual rule you created?
    
    s/rob