Conference azur::mcc

This is being worked on for V1.2.

I do not believe there is a short-term work-around, since V1.1 "maximizes"
alarm severities, so any alarm rule that you write with a lower severity will
not be able to turn the icon's color back to normal.

Sorry.

Thanks for the prompt response.

Will the V1.2 have the following features:

- Auto-discovery function in MCC: it can automatically detect
  an unregistered entity hooked into the network without.

- Auto-configure function in MCC where the entities are 
  automatically group into according to their network-group.

- On ULTRIX, and what is the positioning with MSU.

Thanks again

Henry Cheung

Will the V1.2 have the following features:

- Auto-discovery function in MCC: it can automatically detect
  an unregistered entity hooked into the network without.

	Yes,  for  things  like  DECnet,  ETHERnet  stations,  Terminal
	Servers, TCP/IP SNMP,  LANbridges.   Not for proprietary vendor
	devices.

- Auto-configure function in MCC where the entities are 
  automatically group into according to their network-group.

	There will be a few options like what domain do you want things
	loaded into.

- On ULTRIX, and what is the positioning with MSU.

	Dick  Andersen,  the Network Management  marketing  manager  is
	developing a position statement now.   The  DECmcc V1.2 product
	will  have all the appropriate MSU functionality  (MIBs,  traps,
	graphs, etc.), run on Ultrix, and be priced  the same. 

Thanks again

Henry Cheung

    Regarding positioning - MCC is a generalized management system, and
    often does not match the features of a specialized system, such as the
    ones that manage SNMP devices.  If you are in a feature war for only
    SNMP devices, MSU will continue to be the system to bid, until MCC can
    be 'tuned' for the SNMP market.  If multiple protocol integration is
    what your customer is looking for, MCC is the best on the market.
    
    bill

    regarding AUTODISCOVERY
    
    	Our customer is concerned about node impersonation whereby some
    evil person brings up a node with the same address as a production
    system in order to try to steal front-end information.
    
    	To the best of my knowledge this will simply blow both nodes off
    the network. We would like to be able to alarm the appearance of this
    impersonating node but MCC seems to have to be able to communicate via
    DECnet with a node to find out about it.
    
    	One option is to use VCS on the production node (impersonatee)
    which will give a DECnet adjacency message (of itself) as the
    impersonator comes up. It would be noce, however, if there were a way
    of getting a DECnet address of an ethernet station and testing if the
    ethernet address and DECnet address were a valid pair. If an
    impersonation is taking place we cannot talk via DECnet but can talk
    via ethernet. Is there any way to do this?
    
    thanks,
    Andrew

> It would be noce, however, if there were a way
> of getting a DECnet address of an ethernet station and testing if the
> ethernet address and DECnet address were a valid pair. If an
> impersonation is taking place we cannot talk via DECnet but can talk
> via ethernet. Is there any way to do this?

NMCC/VAX ETHERnim does this today (sort of).  If a SYSTEM-ID message
(containing both the hardware & DECnet Physical addresses) is received with
addresses that don't match what's in the database, then a message is
generated in the history file indicating "address mismatch".  Of course,
this only works for stations which support MOP SYSTEM-IDs,  which does not
include most of the third-party equipment.

There is a headache involved here for the network manager as well, since
if you take this to the extent that you've indicated, you MUST update your
database if any Ethernet controller is swapped out.  You'd run into the
same kinds of problems that software which ties it's license to the
Ethernet controller address finds itself in.

						Wayne

    Auto-Discovery for V1.2 works for Ethernet Connected devices and may
    be extended to IP connected devices BUT general Auto-Discovery will
    appear step by step over multiple releases. I recently had a T1 
    customer assume they would get Auto-Discovery for V1.2 because
    they heard the message that it worked in general. In DEC we tend
    to think that the LAN is the network and if we solve the LAN problem
    we have solved the whole problem. In truth, our V1.2 Auto-Discovery
    is targeted for Ethernet connected and TCP connected entities. 
    
    wally

    Wally, just to clarify some more, will DECmcc V1.2 discover Ethernet
    connnected devices, or devices connected to the SAME LAN as the DECmcc
    V1.2 station?
    
    s/rob

    Regarding .0
    
    This is currently an issue for me.  My customer is very much interested
    in having the icon color return to normal once the alarm condition has
    been corrected.  I have tried writing an alarm rule that changes the
    color back to clear, but as mention in one of the previous replies, it
    does not work.
    
    I've been thinking about submitting a batch mode command procedure that
    periodically resets alarms for a specific domain.  This is not
    preferrable since it will undoubtedly (at some time or another) reset
    alarms just after an alarm has fired, thus defeating my ultimate
    purpose.
    
    I would appreciate any ideas or work-arounds anyone might have.  I
    would also like a little more info regarding how V1.2 will perform this
    function.
    
    Thanks,
    Dan

it isn't a two minute explaination, but I will try my best.

to clear a rule in V1.2 the alarms fm will watch to detect when the
rule condition has cleared. At that time it will generate a specific
event (clear event) which the notification FM will pick up. Based upon
the value of certain fields in the event, which the FM passed back to
the notification PM (a new module in 1.2) will determine which entity 
and event is to be cleared. It will then send a "clear this event on this
entity" request to the iconic map.

A bit unclear (pun intended), but hope it helps.

As to a work around, I know of none.

jill

    
    More on the last reply:
    
    This feature will only work for rules whose Expressions that are
    not CHANGE_OF or OCCURS expressions.
    
    aud...
    

>    More on the last reply:
>    
>    This feature will only work for rules whose Expressions that are
>    not CHANGE_OF or OCCURS expressions.
>    
>    aud...
 
I'm sure there are all kinds of reasons for not adding this support but
these alarm types could be the main thrust of many monitoring systems
{including ours :-( }. Will we at least get the ability to write a
second rule at severity=clear to normalized the icon yet have it still
be available for further alarm notification?? Will a -PLEASE- help?   

brad...

Hi Brad,

The main problem we have with generating rule clear  event with
OCCURS function is that Alarms has no way of knowing what is 
the complimentary event that represents "Alarms clear condition".

The same argument hold good for CHANGE_OF function (which is really 
a poor man's event generator!). 

Now OSI clearly defines how a previously declared alarming condition
can be cleared. Let me quote OSI here: 

+-------------------------------------------------------------------------------+
|(ISO/IEC JTC1/SC21 N 4858 ISO/IEC  DIS 10164-4 Section 8.5)                    |
|                                                                               |
|The clear severity indicates the clearing of one or more previously reported   |
|Alarms  for this managed object that have the same                             |
|        1. Alarms type                                                         |
|        2. Probable clause                                                     |
|        3. Specific Problems (if given). Multiple associated notifications     |
|           may be cleared by using correlated notification parameter.          |
+-------------------------------------------------------------------------------+

In V1.2 we are going to make Alarms Report OSI compatible. So Brad,
all you will have to do is create a rule on the same entity with 
same Alarms type (enumerated value) and same Probable clause, define
Severity to be "Clear" and you should get what you are asking for in .1


Hope this make you happy :-)


- Anil

P.S. The Specific Problem field is an optional field and will not be supported
     by Alarms.

> Hope this make you happy :-)


Your change of support has come remarkably quick. I think I'll use
-PLEASE- more often. :-)  :-)

brad...

    I wonder if someone has tested this feature in V1.2 (or T1.2). I have
    the same problem of clearing an event automatically.
    
    Raja

>    I wonder if someone has tested this feature in V1.2 (or T1.2). I have
>    the same problem of clearing an event automatically.
    
Hi Raja,

This one is near and dear and yes I have tested it. If I remember right it
worked with both Alarms and Notify. One alarm for 'circuit down circuit fault'
at severity=critical and another for 'circuit up' at severity=clear. The
line toggled back and forth between red and black. The same was tried for
two notify commands with similar results. Bugs found were 'adjacency events'
cannot be processed and sometimes colors do not reset between domains correctly.
Also tried was a polling alarm which had a simple expression of substate <>
none. Red when the circuit was down and it toggled back when it found the 
circuit back up. Other than these two bugs (which are critical and it looks
like there is work going on to solve them) life looks much better in V1.2!!

best regards,
brad...

    maybe I can clear something up. Brad what you are talking about works
    fine, I believe what Raj and the others are discussing if the clear
    event generated by a rule when the condition being monitored no longer
    is meet. There was a problem that you have heard us refer to as
    "propogation". This means that in certain circumstances the color
    changes (like critical to cleared) were not working correctly. Dave
    Wong has been working on correcting these problems, and I have been
    informed that the changes look great and should now correctly handle
    the alarms clear event correctly in all circumstances.
    
    I am sorry I don't know the details of why is does and doesn't work for
    different people/installations.
    
    jill