HP Openview Slowness.

Mailman List Mirror (Read Only)
1

Hello.

    As part of a network I'm working on, I've install HPOpenView NNM
(first time, I've only used free/cheap stuff in the past) on a Sun
Ultra5, and it's performance is less than stellar. It takes between 30
seconds and 5 minutes to traverse from one map to another (either up or
down). This occurs no matter how many (or few) objects are on each
submap.

My two questions are:

1> Is this normal (or did I do something wrong with the software setup)
2> If you are running NNM, what platform are you using, and do you find
it satisfactory in responsiveness/etc.

Thanks!
-Scott

2

If you begin to use commercial soft after free one, then:
- don't drop free soft, ypu'll use it anyway;
- increase memory, CPU and disk up to 2 - 4 times (if you had 64RAM,
install 512);
- be ready to be disappointed;

Through HP OV is not bad piece of software.

3

"Alex P. Rudnev" wrote:

If you begin to use commercial soft after free one, then:
- don't drop free soft, ypu'll use it anyway;

I know :slight_smile: I'm doing HPOV because the 'suits' want a pretty network map on a projector
somewhere. MRTG/etc will still be very present in the system :slight_smile:

- increase memory, CPU and disk up to 2 - 4 times (if you had 64RAM,
install 512);

Noted, thanks.

- be ready to be disappointed;

:slight_smile:

Through HP OV is not bad piece of software.

It's not, but I am disappointed it's not more router-centric. I appreciate the need to
monitor workstations, but I've got multitudes more network devices that workstations/servers.

Thanks for all the responses everyone.
-scott

4

I use our own monitoring system, and the only complain I just have from
the 24x7 staff is the absence of the graphic map.

To solve this, I need some package (like 'xfig') allowing me to dray
graphic map in the vector style, and define some attributes (color,
blinking, etc) dynamically (defined by the external or embedded script).
THat's enougph for the middle-size networks.

What's about HPOV and other mosters - good tools for the static networks
having good resources to execute such big programs. I do not know an
examples when NOC people are satisfied from this tools (usially they are
used to draw the map, and mgrt or 'snmpstatd' to build reports and
graphs).

Btw, see http://noc.bn.ru/~alex/MON/ for an example of 'snmpstatd' output.

Alex.

5

And the worst thing, If someone think _SNMP IS SUITABLE PROTOCOL_ he is
wrong. In case of CISCO (as an example) we was caused to use boths 'SNMP'
and 'rsh show ....' methods to get appropriate information. I think
those who developed SNMP was the childs of the hell (it's terrible
example of _how you should not develop protocols_; for example, compare

'rsh -t 120 -l monitor "show ip route"'

request and requesting ip route table by SNMP; compare 'sh interface
Serial0' and SNMP (10 - 20 different MIB tables with the very euristic
INDEXES), try to ask _how much BGP router does router have_ or _how mach
packets was received by ISL sublink_ etc etc. If someone answer _that's
because of CISCO don't like SNMP_ I can't agree - no, thet's because SNMP
is wrong protocol at all.

Such protocol should be:

- ascii text based;
- with domain-like names, with the asterisk;
- based on reliable UDP and/or TCP;
- use something like MD5 checksumming for the simple protection.

For example, I'd like to ask

'BASE 'router'
  GET interface Serial*
'

and get
ORIGIN router.interface.Serial1
in-packets: 223334 u32
in-errors: 1122 u23
in-bytes: 124563874 u64
....
ORIGIN router.interface.Serial2
....

(1) TEXT mode, no terrible binary octets, etc etc;
(2) SIMPLE variables, withouth terrible MIB descriptions (they are not
usefull here);
(3) Another hierarchy (interface.variable, not variable.index)
(4) simple addition private variables

CISCO.in-bad-frames: 223344
instead of (as now)

vendor.cisco.mgrt....interface.lapsha-na-palochke.INDEX

etc etc...

And then, if the protocol (SNMP) is BAD, don't think the tools for this
protocol should be GOOD.

// And compare this with the WEB interface implemented into some new
routers and switches - simple, robust, can be used easily, and 100 times
more flexible. Through it's only simple interfaces with the operator, not
for the tools, for now.

Alex.