Search results for query: *

The best way is to watch the events on the alarm browser instead of a large map. For some critical events like core router link down, you may set an audio alarm to alert the NOC staff. Cycle through the map is not a good way to alert the problem.

Attached the perl script for your reference. Please note that it requires the lib from MRTG. Fill in the IP in @hosts and the write community string in @test. #!/usr/bin/perl -w #use lib "c:\\mrtg\\lib\\mrtg2"; use SNMP_util; my @hosts = ( '10.10.10.1', '20.20.20.2'...

CiscoWorks can only manage Cisco products. You may use HP Openview to monitor your network. Actually, different vendors will implement their own propiertary protocols in some features like link aggregation, spanning-tree fast recovery, trunking, etc. So don't expect everything work in a mixed...

You may write a PERL script using snmpset to get the config regularly to a server. Please let me know if you want to have the code.

In addition to 8880, you have to open port 3700, 9999, 2345, 2346.

Check the syslog messages. And you may have more idea.

We are using Big Brother to monitor >10 sun boxes. It is a great tools which allows us to put in some customization scripts. Besides, we also use it to monitor network traffic polled from MRTG.

It is impossible to install a compiled software to a different unix platform. You must get the solaris version for installation.

HPOV Web interface is not a stable application. I don't suggest the operation team to use it. If you want to access from a windows PC, you can install a X server and open the HPOV map natively.

If the alarm database corrupted, you can delete the database only. No need to reinstall HPOV. Event Database, Topology Database and Map are individual components (db files) in HPOV.

We are running HPOV and CW2k on a SUN e250 with 2G RAM to monitor a mid-size network (several hundreds of network devices). But HPOV is not a stable application. Regular reboot is inavoidable (about once every 2~3 months).

seedfile is the best approach.

I guess there is some problem in your topology database. If it happens on a particular device only, I suggest to add the IP to netmon.noDiscover. You will still have trap received and poll info regularly if it is already on the map. For long term solution, I suggest to check to topology...

On UNIX platform, the HPOV license binded to the IP address of the station. I'm not sure whether windows ver is the same, if yes, you may need to re-apply the move license from HP first.

Sure. I have a similar environment. One NIC to internet and the other to private segment. The HPOV will discover the topology automatically.

Both sound alert and email notification are supported. But you may need to modify individual event type (from the event configuration menu). The detail can be found from the HPOV user guide.

If autodiscovery is turned on, it will be discovered again and again. The best solution is to add the IP address to the netmon.noDiscover file and then restart netmon. You may find the detail steps in the HPOV user guide.

For those inconsistent objects, you may delete them from the topology database by : ovtopofix -r <object-name>

I guess the authentication failure message trap is sent from a network device. If there is a device on your network that snmp poll your device with a wrong community, the authentication failure message will appear. You may trace the logging of that particular network device.

I have the same experience too. But after I deleted the eventdb files and restart HPOV, it operates normally (several months ago).