Advertisement
If a device is not responding to a demand poll, follow these steps:
Poll a different device to see if it responds to SNMP. If the device responds, HPOV is not the problem.
Ping the device that is not responding. If the ping works, the devices are communicating.
A firewall in the communication path can block ping and SNMP packets.
Verify that the SNMP community strings are correct.
Try polling the device from the HPOV command line. For example, enter the commands snmpwalk and
snmpget.
The syntax for the snmpget command line is as follows:
snmpget [options] node object-id [object-id]...
Options:
-d
-v version
-c community
-p port
-t timeout
-r retries
Overpolling the wrong OIDs overloads CPUs and crashes network devices.
Traps appear in the All Events Browser, which reports what is happening in the network. The events are
updated every few seconds. Understanding the severity level of a trap is important. One trap can be
critical; whereas, another trap can be informative.
Other ways to look for traps include:
Using a network analyzer to capture and inspect data on the line.
Using the snoop Unix command to sniff the line and inspect data.
To monitor the limits of a network, configure thresholds to set off alarms. For example, set up an alarm
for a CPU that sustains a 98 percent utilization for a specific amount of time.
Common mistakes include:
Setting thresholds too low.
HPOV is in a constant alarm state because you do not understand how to operate or monitor the
dynamics of the equipment.
dump ASN.1 packet trace
protocol version (1 or 2c)
community string
remote port
retransmission timeout (1/10th seconds)
maximum retransmission attempts
Advertisement
