Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe
From: kwe@buit13.bu.edu (Kent England)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SNMP monitors
Summary: disappointment
Message-ID: <66559@bu.edu.bu.edu>
Date: 19 Oct 90 16:05:43 GMT
References: <9010181639.AA14322@po.cis.brown.edu>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@buit13.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston U. Information Technology
Lines: 87

In article <9010181639.AA14322@po.cis.brown.edu>
 Steven_Carmody@BROWN.EDU writes:

>... I'd like to get a sense of what's out there. So far, I
>can see three groups of products: 1) the PC-based monitors (wollongong, the
>recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a
>large number of commercially available, UNIX based monitors (often from
>router vendors)...
>
>The question is -- are there any generalizations which can be made about
>each of the categories?

	I can generalize.  :-)

1)	I don't like PC based packages because I need workstation
power and multitasking.  You will need multitasking and virtual memory
to do good fault management and data gathering.  Of course, you could
use a pile of PCs.  And I do understand the need for a low end PC
package for smallish PC networks.  So I would say they are OK for
small nets with unsophisticated tool requirements, but not suitable
for largish nets.

	The Proteon Overview PC tool is pretty good, even in its
earliest release, with which I am most familiar.

2)	The NYSERnet stuff is still pretty good in comparison to other
software, and that is disappointing.  It indicates that the
development of tools has stalled or gotten sidetracked.  Some points
of interest:

3)	Fancy graphics.  Migrating from an early X window environment
to Motif doesn't buy the network manager a lot.  This has distracted
developers excessively.  But Motif is very pretty; witness the
Cabletron displays.  Nice pastels, shadows, pictures, etc.  Value?  To
be determined.  The people running the InterOp show network used ping
and traceroute a lot, but then they may be old fashioned.  :-)

	Databases.  A database is an important feature of an advanced
network management fault monitor and data gatherer.  Early
implementations fall short in the ease of use category.  We need some
database interfaces that match the window environment more closely.

	Configuration.  It is very difficult to adopt or change a tool
in a large network if the tool does not help the network manager
configure the tool.  This is one area where the NYSERnet tool is just
awful, requiring the same data to be entered multiple times
consistently in the snmpxmon.cf file.  Dynamic configuration of
commercial products is on the drawing board in the tools I have
examined closely, but is not available in a production release.

	Data gathering and interpretation.  This area has been
entirely neglected in the tools I have seen.  Data gathering and
analysis should be database driven.  Report generators should be
supplied and should be customizable.  The database must be accessible
outside the network management tool.  The database must be custom
extensible to deal with such local issues as inventory and cost
accounting.  There should be utilities for automagic aging and
compression of performance data timelines, reducing the demand for
disk space growth and easing back-up and archiving.  No one is
addressing these issues, in the tools I have examined.  NYSERnet is
still as good as any of the other tools, which is disappointing.

	One reason I think that progress is disappointing is that the
network management market is limited.  Developers are getting enamored
of the "Distributed Computing Environment Management".  I have heard
more than one developer talk about stuffing every conceivable variable
and extension into the MIB for managing PCs, workstations, and servers
and this is a distraction away from the purely Network Management
needs of largish networks.  However, I understand that tools for DCE
management are useful.  Sun's tool is interesting.  If it saves
sysadmin time, it's a good thing.  DCE management tools have a wider
market than purely NM tools.  But DCE management is more embryonic
than NM, so I would rather see some vendors concentrate on solving NM
problems before turning to DCEM.  They could learn from us.

	One bright note: Cabletron's Network Virtual Machine and
object oriented development environment are powerful architectural
elements of next generation tools.  The NVM can scale well, and holds
out some hope of unified Internet management (if such could happen
politically and organizationally and could be standardized for
interoperability).  The OOP model in the Cabletron Spectrum tool is an
apparently powerful technique for allowing user customization and for
MIB and device tracking.  I think object oriented techniques will
prove very useful in managing development of sophisticated NM tools,
but that is just my embryonic gut feel; it has yet to be demonstrated.

	--Kent