Conference azur::mcc

2435.0. "Customer Feedback on DECmcc - Community Names Unacceptable" by PJWL::LAMB (Peter Lamb - GSG Santa Clara MAIL=MUTTON::LAMB) Wed Feb 26 1992 23:08

Hello,

One of my customer's is currently evaluating DECmcc in
a run off between it, HP's NETview, SUN's SUNet and
Novel's product (the name escapes me).  We have loaned them 
Ultrix DECmcc FT 1.2.4 and are doing it as a locally supported
field test evaluation.  They are a pretty high powered networking
group (ever heard of Carl Sunshine?) and it was felt that we really
had to put our best foot (or product)forward.  We would have 
preferred an "official" field test but were told by product 
management that this was the best we could do....

So far (they've had it 1 day) but are pretty impressed.  I managed
to pull one of the key people aside and asked him what he thought
after a fairly extensive demonstration and he indicated that he 
beleived it was clealy superior to the "generic" SNMP tools they
had (like SUN's) and thought it was probably roughly comperable to
the Novel product (which costs $100,000!).  Note: Novel's hub 
management is impressive though! 

BTW, they really liked the autocad backdrops!!  I managed to get a
floor plan of my building in autocad and used the tool mentioned
in this file to convert it.

Clearly, we have some major advantages around true 
enterprise management.  However, I thought it would be
beneficial for you to hear some of their concerns too.

1) The implementation for doing community names (using
Operations "access" and setting the password. Is 
unacceptable.  They have many different systems and several
different groups which use different community names.  DECmcc's
approach forces the network manager to remember which node
use which community name.  This information should be 
stored in the repository as part of the registration.  

Note: all of the other products mentioned above have some
way of handling this.  Most seem to do it with a simple
"community.conf" file in /etc.

My appologies if I have missed something here, I'm fairly
new to the product but after reading notes 1121 etc. I believe this
is the best we can do...

2) Auto-config (both DECnet and TCP-IP do not provide 
enough information.  Admittedly, this could be something
I am doing wrong, however, a quick auto config of their 
network using both DECnet and IP tools did not put any
of the nodes  on a wire drawing and more importantly did
not show which side of the routers the nodes are located 
on.  For example, using the TCP/IP tool and looking at 
all of their routers and all of the nodes in one particular
subnet (containing 100 spread geographically) lump all of 
the nodes into one domain and did not show which nodes are
on which side of the routers.  According to the customer HPs 
product was able to actually connect the nodes (with lines) and 
showed the relationship between the nodes and routers.

3) Alarms - The current documentation on FT 1.2 seems to
be particularly lacking in information regarding how to setup
a simple node status alarm i.e. to let you know when a 
particular node goes away.  Its interesting to note that
all of the other products do this one alarm automatically
the minute a TCP/IP node is registered.  When I first 
brought the product up (with nodes still on it from when 
I had it running at DEC, the first thing they asked me was 
why were those nodes not red??  I'm not sure I agree with
this; I think you rapidly reach information over-load 
however, I do think we could make it MUCH easier to do 
a simple node status alarm (for both DECnet and TCP/IP).

Also note, the examples that are in the back of the FT1.2
TCP/IP interface manual are really hard to translate into
something that makes sense with the new window interface
to the alarms.

On a related topic, the next thing they will almost certainly
want to do is issue the same alarm for several nodes.  Is
there any easier way to do this short of creating a script
and editing it for each of the nodes??  For example, ideally
one would like to be able to say...

DEFINE DOMAIN xxx rule xxxx (for all nodes with location 
or some other group type) = my collection  EXPRESSION...

I guess thats all for now.  When I get more information from them
I'll document it here.

Regards,

Peter Lamb

After reading some other notes in this conference I realize
now that I should have copied up the maps from the directory
that was created by autoconfig...  however this still doesn't
address the router relationiship problem.

Peter

RE: base note

>  1) The implementation for doing community names (using
>  Operations "access" and setting the password. Is 
>  unacceptable.  They have many different systems and several
>  different groups which use different community names.  DECmcc's
>  approach forces the network manager to remember which node
>  use which community name.  This information should be 
>  stored in the repository as part of the registration. 
>
>  Note: all of the other products mentioned above have some
>  way of handling this.  Most seem to do it with a simple
>  "community.conf" file in /etc.
>
>  My appologies if I have missed something here, I'm fairly
>  new to the product but after reading notes 1121 etc. I believe this
>  is the best we can do...

 No, you didn't miss anything: the Community Name must be set
 using the password qualifier.

 Storing Community Name(s) (possibly one for read-access and a different one
 for write-access?) as part of Registration (or as a settable write-only
 attribute?) sounds good to me. Any security concerns?

						Chris

 P.S. We'll add it to the list for next time.

 

    What about an answer to the Alarms question in .0 ?   MSU does a really
    nice job of "pinging" the node to determine if it is up or not.  This
    is done dynamically, without the need to write an alarm rule.  
    
    Having such a capability would be a big seller for DECmcc.  This could
    be done for all nodes regardless of protocol.  Also, when the node
    becomes reachable again, the icon could then change color from red to
    green, for example.
    
    I've had to write hundreds of alarm rules just to accomplish this task
    for all nodes.  MSU does it dynamically when you add a node.
    
    Also, I hope the "single rule for multiple entities" capability makes
    it into V1.2.  Managing several hundred alarm rules can get old very
    fast.  I have one customer who refuses to use DECmcc just because of
    this.
    
    -Dan

>    Also, I hope the "single rule for multiple entities" capability makes
>    it into V1.2.  Managing several hundred alarm rules can get old very
>    fast.  I have one customer who refuses to use DECmcc just because of
>    this.

I'm happy to say that "single rule for multiple entities" will
be available in V1.2, although with some limitations.
Reachability won't be automatic, but it will be MUCH easier to
set up.

-- Erik