Task 7—Using HP OpenView to Create the SNMP Framework

• Discovers all the devices in the network.

• Functions as the central-starting point for other element managers (EM). After HPOV is installed, the remaining components of the network management architecture are built around HPOV.

• Resides on the same Unix workstation as CiscoWorks 2000 Resource Manager Essentials, which gathers the following database information from HPOV:

  • Device names and IP addresses

  • Community strings

Figure 25: Other Element Managers Start from HPOV

Note   This section assumes that HP Network Node Manager Release 5.0 is already installed on a Solaris workstation.

Note   If a daemon is not running, try restarting it by using the commands ovstop daemon-name and ovstart daemon-name. If a daemon is still not running, an HPOV license issue may exist. For more information, go to http://www.openview.hp.com

Step 3   From HPOV, enter the SNMP community strings and target loopback IP addresses for each Cisco IOS device. From the Options menu, select SNMP Configuration.

In the SNMP Configuration screen, enter the following information:

• Target field—The target loopback IP address (for example, 172.21.10.1)

• Community field—The Read-Only (RO) community string (for example, 5urf5h0p)

• Set Community field—The Read-Write (RW) community string (for example, 5crapmeta1)

Note   Accept the default SNMP parameters in the other fields in the SNMP Configuration screen.

Caution Do not use the SNMP community strings "public," "private," or "cisco." These strings are well-known within the industry, and they are common defaults. These strings are open invitations to attacks—even if you use filters.

Figure 26:
SNMP Configuration: Loopback IP Address and Community Strings

Step 4   Click Add and Apply to submit the entries.

When the HPOV daemons start, HPOV discovers the devices in your network. Depending on which discovery options are configured, the device map is based on Layer 2 or Layer 3 information. Choosing discovery options is outside the scope of this document.

Step 2   Inspect the top-level map of the discovered devices in your network.

Figure 27:
The Top-Level Device Map

• Green—The device is up.

• Yellow—Multiple interfaces are down.

• Light blue—One interface is down.

• Dark blue—The device is detected, but it has never been managed. The device is unreachable.

• Red—The device is down and unreachable.

Step 3   Select a device icon in the map (single click).

Step 4   Go to Fault.

Step 5   Select Network Connectivity: Poll Node.

Demand polls enable HPOV to:

• Detect the sysobjectID (vendor ID) for each Cisco device.

• Associate MIBs with each device.

• Collect interface information.

Table 31: Important Fields to Inspect In the Polling Results

Field	Description
Changing SNMP sysobjectID to .1.3.6.1.4.1.9.1.162	Indicates SNMP is working and the system identifier for the device was found. This field appears only the first time a device is successfully polled. HPOV changes a generic router icon into a Cisco device icon after the sysobjectID is found. The trailing number series, for example .1.3.6.1.4.1.9.1.162, is the OID that identifies a node as a Cisco device.
Supported versions	Describes which versions of SNMP are supported by HPOV, such as SNMPv1 and SNMPv2C.
Verify node name	Verifies the node name is valid.
Interface	Confirms the interfaces were successfully pinged.
Get system description	Verifies that the system description information was collected, so you can identify the software version running on the device.

Step 2   From the Fault menu, select Test IP/TCP/SNMP.

This action performs one ICMP echo, one TCP connection, and one SNMP get. SNMP is working if the "OK" message appears under the SNMP Get field.

Step 2   Ping the device that is not responding. If the ping works, the devices are communicating.

Note   A firewall in the communication path can block ping and SNMP packets.

Step 3   Verify that the SNMP community strings are correct.

Step 4   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                  dump ASN.1 packet trace
     -v version          protocol version (1 or 2c)
     -c community        community string
     -p port             remote port
     -t timeout          retransmission timeout (1/10th seconds)
     -r retries          maximum retransmission attempts

Caution Overpolling the wrong OIDs overloads CPUs and crashes network devices.

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.

Setting up alarms for different kinds of traps is outside the scope of this document.

To verify that HPOV is receiving traps from devices in the network, follow these steps:

Figure 30:
Traps in the All Events Browser

Step 2   Force a trap to be sent into the browser by manually causing a fault. Pull out a card on a Cisco device or shut down an interface.

Caution Do not shut down a communication link that can cause a service outage.

Step 3   Look for traps in the browser.

• As remote users dial in to an access server, it is normal behavior for asynchronous and serial interfaces to regularly go up and down.

• On an average 20-minute call, one modem normally produces three alerts. At approximately 6 alerts per hour, one modem can produce up 144 events each day. One Cisco AS5800 fitted with 1296 modems can produce up to 186,624 modem events per day.

To unmanage the asynchronous and serial interfaces for a Cisco access server, follow these steps:

Figure 31:
Available Interfaces and Ports for a Cisco AS5800

• Green—The port is managed, and it is up.

• Blue—The port is managed, but it is administratively down on the Cisco IOS.

• Tan—The port is unmanaged.

• Red—The port is managed, but it is in a down state.

Step 2   Find the following interfaces:

• Serial interface channels (B and D channels). For example, Se1/0/0:6 and Se1/0/0:23

• Asynchronous interfaces. For example, Async 1/2/1

Step 3   Select a group of ports to unmanage. Draw a box around the ports, or select them individually.

Step 4   From the Map menu, select Unmanage Objects. Unmange all ports except the T1 trunks, loopback management interface, and Ethernet interface. Statistics are polled from managed ports.

Note   You must unmanage the serial and asynchronous ports, which appear tan.

Tips When the status of an object changes (to managed or unmanaged), HPOV switches to synchronization mode.

The following procedure saves you from having to refresh all your submaps each time a new device appears in the network. After you implement the following procedure, new devices will appear in the New Object Holding Area.

Caution Deleting a device from a submap removes the device from the database. To load a device back into the database, see the "Using the HPOV CLI to Enter a Device into the Database" section.

To manually re-structure device maps to adequately represent your network and turn off the automatic-layout function for the top-level map, follow these steps:

Figure 32:
Top-Level Map Adjustments

Step 2   Go to View.

Step 3   Select Automatic Layout.

Step 4   Choose Off For This Submap.

Use a discovery filter to:

Sometimes HPOV discovers too many devices. If HPOV discovers devices beyond your target network, such as the entire Internet, the performance of the Unix host decreases significantly. If the device maps begin filling up with networks, routers, and other devices that do not belong to you, use a discovery filter.

After a filter is set up, HPOV will not discover devices unless they are defined by the filter. Edit the filter each time a new device is added to the network.

• Node list—A list of specific devices. In the example, the list is called TheNetNodes. There are two devices in the list: AS5800-1 and AS5800-2.

• Filter list—A list of attributes for the specified devices. In the example, the list is called TheNetFilters, which specifies the filtering attributes for the devices in the node list. For example, all devices must be SNMP compliant and Cisco devices.

To manually load devices in to the HPOV database by using the CLI, follow these steps:

Note   Enter devices by using a DNS format (IP address then hostname). Use spaces (not tabs) to separate IP addresses from hostnames.

Step 3   Restart the netmon daemon by entering the following commands:

aurora:/ ->ovstart netmon

aurora:/ ->ovstatus netmon

 object manager name: netmon
 state:               RUNNING

 PID:                 12812
 last message:        Initialization complete.
 exit status:   
 

Step 4   Go to the GUI and look for the new devices that appear in the new object holding area.

Step 5   Perform a demand poll on each device to get the sysobjectIDs. After the demand poll is performed, HPOV puts each new device into its correct place in the map.