In my experience...
a) I've found that you still end up writing quite a bit of "Agent"
code on the "TEC" side of the house. Advice... make sure you have
some good perl programmers in-house.
b) NetView gives you topology, and quite a lot of information about a node
(addresses, # of interfaces, description, location, etc), where as TEC
does not. This does allow you to incorporate information into NetView
decisions... that you don't normally get with TEC.
c) You end up writing a lot of roll-your-own code on the TEC-side, and you
use the "postemsg" command-line program with this (which I believe is
connectionless... correct me if I'm wrong).
d) Losing events with SNMP -- yes it is possible to lose events this way,
although in testing I've done across our WAN... this was about 1 in
1000.
LAN should be even better.
If TEC gets swamped with events = same result (i.e. you lose events).
I can't say one form of loss is better than the other.
e) TEC has a better rule-processing engine (out-of-the-box), but you can
also buy one for NetView. In fact, I believe "MasterCell" sells a
Prolog engine that understands baroc, and I believe integrates into
NetView. Don't know if its good or not, but it looked interesting!
Personally, I'd probably go with a rule-engine with a language that more
than a half-dozen people know. Maybe Seagate's NerveCenter.
f) Tivoli can supply you with agents for TEC. A lot of other vendors can
supply you with generic SNMP agents that provide the same function with
NetView. The decision is up to you... "Framework" (vs) "standardized
SNMP
agent". Both have advantages/drawbacks. If you like one vendor to
supply
everything... then you'd probably be better served with the framework
approach.
Just remember... if you install "passive" agents (framework or SNMP),
you
still should monitor them via polling to make sure that they (the
agents)
are up-and-running.
My Advice...
a) Test before you buy it.
b) If you can't test it... don't buy it.
c) Don't buy it just because the demo looked nice!
c) Don't make decisions based on marketing hype. For example... saying
that
SNMP isn't reliable enough, because it connectionless.
Ok.. that's nice to say, but prove to me that what you're selling can do
better! Roll your box in, and do the tests!!!
Suggestion... create a test that sends 100,000 events, and include some
event-bursts (like in real life). Have it run for 24-hours (that's
only
1-2 events/sec). Look at the results. Make a decision!
Decide what REALLY works, and what doesn't. ...Then buy it!
Not much of an answer... but it made me feel better!!!
Have fun !!!
Gary Boyles
-----Original Message-----
From: Leonard Bocock [mailto:leonard.bocock@NZ.UNISYS.COM]
Sent: Monday, February 08, 1999 1:43 PM
To: NV-L@UCSBVM.UCSB.EDU
Subject: Re: NETVIEW vs. TEC
You need to consider these points:
NetView is great for SNMP device management.
NetView is SNMP based (connectionless), TEC is ORB/socket connection based
(assuming TEC is communicating with Tivoli framework products). If you have
devices (e.g. routers) sending SNMP traps to NetView, you have no security
they
got to NetView. On the other hand, communication between TEC and Tivoli
framework enabled devices is more reliable being connection based.
Yes, NetView polls, but so does Tivoli aents such as Sentry, however Sentry
agents run on the local host, removing any network timing/failure component,
whereas NetView polls from the closest MLM.
TEC has a fully programmable rules engine which is limited only by your
skills
in Prolog. NetView's event rules engine is far more limited. What you're
getting for the 50K is a far more sophisticated event rules engine - you
need to
decide if you need that or not. You can always write rules in a scripting
language but Prolog is object orientated - ala inheritance and all that good
stuff that is supposed to stop you writing heaps of code.
Bear in mind that currently TEC has a maximum throughput of around 15 events
per
second (this is dependant upon the host speed, and complexity of rules but
its a
good rule of thumb). If you get thousands of node downs when a router
fails,
TEC will get swamped.
At the end of the day, we have taken this approach;
NetView for polling node up/node down, and network management - it is good
at
this.
NetView for SNMP enabled devices that are not Tivoli framework supported.
Tivoli framework for framework enabled devices.
Rgds.
Holger Heimann <hh@IT-SEC.DE> on 08/02/99 21:52:24
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
<NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: Leonard I. Bocock/NZ/Unisys)
Subject: NETVIEW vs. TEC
I'm trying to understand the practical differences (not the marketing or
historical ones) between Netview and the Tivoli Enterprise Console (TEC) for
*monitoring* purposes.
We habe a Netview 5.0 Demo Version here under NT (yuck!) and know the TEC
just from papers and a recent demonstration.
As far as I understand, Netview is basically SNMP based and works by polling
network devices. TEC supports agents and is therefore somehow passive and
capable to monitor almost everything by design. Both support thresholds,
rulesets etc.
On the other hand, one can also configure traps and actions in Netview as
well as it can be used with external agents that monitor whatever you like,
like the TEC. So one can, at least for monitoring, do roughly the same with
both.
So, if I want to get something from green to red on some well defined
condition and execute some action then, I finally can use both, can I?
What am I missing for the 50K$ price-difference?
Thanks,
Holger Heimann
www.it-sec.de
|