HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

5.1 SEEDING INITIAL DISCOVERY

Because the default behavior of NNM is to discover up to the first router, NNM provides a configurable way to specify a list of network devices that should be discovered. Because the local network may not be a very interesting (and possibly not a very useful) network, the discovery process can be augmented by the use of a seed file. The purpose of a seed file is to allow an administrator to define the portion of the network for NNM to discover and manage.

5.1.1 Setting NNM Environment Variables

When performing command-line tasks for NNM, it is advantageous to set the environment variables. For your convenience, NNM provides several environment variable files in the directory $OV_BIN on UNIX systems. A script exists for Bourne, POSIX, and Korn shell users (ov.envvars.sh), C shell users (ov.envvars.csh) and even one to be used from a Perl script (ov.envvars.pl). If you are using a Bourne, POSIX, or Korn shell you can source this file in your profile, /etc/profile, or from the command line by typing

/opt/

OV /bin/ov.envvars.sh

making sure to put a space between the "." and the directory path/ filename. To verify that the variables are set, type

set | grep

OV

| more

Listed here is an abbreviated list of the variables available. Throughout this book variables such as $OV_CONF, $OV_LRF, and so on, will be referenced.

OV_BIN=/opt/OV/bin
OV_BITMAPS=/etc/opt/OV/share/bitmaps
OV_CONF=/etc/opt/OV/share/conf
OV_CONTRIB=/opt/OV/contrib
OV_DB=/var/opt/OV/share/databases
OV_DOC=/opt/OV/doc
OV_FIELDS=/etc/opt/OV/share/fields
OV_HEADER=/opt/OV/include
OV_HELP=/var/opt/OV/share/help
OV_LIB=/opt/OV/lib
OV_LOG=/var/opt/OV/share/log
OV_LRF=/etc/opt/OV/share/lrf
OV_MAIN_PATH=/opt/OV
OV_MAN=/opt/OV/man

For Windows systems, environment variables may be defined using the

ov.envvars.bat file and referenced using %OV_CONF%, %OV_LRF%, and so on. The

ov.envvars.bat file is located in the %OPENVIEW%\bin directory where %OPENVIEW% is the directory specified when installing NNM.

5.1.1 netmon: the Discovery Process

netmon is the background process responsible for discovering network devices.^[2] The

netmon configuration file,

netmon.lrf , can be configured to reference a seed file. The seed file is a list of systems, typically routers that will direct

netmon in the discovery of the network.

^[2] NNM 7 has separate processes associated with extended topology discovery.

The seed file is an ASCII file containing a list of IP addresses and hostnames, one per line. The contents define the network management domain. Typically the devices listed in a seed file are routers, but they can be any devices containing an arp cache. NNM will discover and manage all interfaces for each entry listed in the seed file (barring a discovery filter or a

netmon.noDisover file entry that excludes the specific interface).

The following is an example of a seed file:

128.1.1.1

128.12.2.1

128.15.5.1

128.22.4.1

mysys.hp.com

The entries in the seed file should include devices that have an arp cache and are SNMP manageable. For example, you could use a UNIX system running an SNMP agent as an entry in the seed file. If the community names of these devices are not public, NNM must be configured with the community names of the devices in the seed file. This will be covered in more detail later in this chapter.

When you use a seed file,

netmon does not automatically discover its own node or network. This allows for third-party network monitoring. You are actually skipping over your network devices to the customer network. If you also want the management station and local network in your database, you need to include them in the seed file.

During the installation of NNM, you may be prompted as to whether or not you want to automatically discover the network depending on the installation method used to install NNM. The default answer is yes when using an NNM-specific CD-ROM and using the "install" command at the root of the CD-ROM. If you plan on seeding the initial discovery, make sure to specify NOT to automatically discover the network during NNM installation. If NNM has already discovered the network and you would like to redo the discovery using a seed file, refer to Section 5.1.4, "Re-discovering the Network."

5.1.2 Excluding Devices from Discovery

If you have devices on your network that you do not want to discover, such as DHCP devices, you can set up a configuration file to exclude these IP addresses. DHCP devices are dynamically assigned, so the devices appear and disappear. DHCP addresses are dynamically assigned to devices. The addresses may migrate between nodes, confusing network management. To NNM this indicates that systems are down, when in reality someone has just gone home for the day. Also, the MAC and IP addresses of DHCP devices change frequently. Both addresses are associated with an object that is stored in the NNM database. When NNM determines an IP address and MAC address mismatch, it generates an internal event. If you're not responsible for managing DHCP devices, you can exclude them from discovery. If you do need to manage them for your service agreements, inform NNM of the DHCP address range using a DHCP filter. Filters are discussed in detail in Chapter 9, "Scalability and Distribution."Chapter 9.

5.1.3 Testing SNMP Connectivity

Before creating a seed file, it is a good idea to verify SNMP connectivity to all the devices you plan on using in the seed file. You can use the

snmpwalk command to traverse the system subtree of the MIB. Execute the following command specifying the IP address of each entry to be used in the seed file:

snmpwalk <IP address> system 

If you receive the error "No response before timeout," you must resolve the SNMP connectivity issue or NNM will not be able to retrieve the device's arp cache, the

ifTable , or the

sysObjectID . These are all important in the discovery and node identification process. One or more of the following reasons can cause this error:

1. The device is not accessible. Verify network connectivity by pinging the device.

2. The device is not running an SNMP agent. Contact the device's administrator.

3. The community name is unknown and must be configured in NNM (see Section 5.4, "Configuring SNMP Community Names"). Contact the device's administrator.

4. A firewall is blocking the SNMP port 161. Request that the firewall administrator open ports 161 (SNMP requests) and 162 (SNMP traps) between the management system and the managed nodes.

5.1.4 Re-discovering the Network

After NNM has discovered your network you may have a reason to re-discover the network using a seed file,

netmon.noDiscover file, or discovery filter. Maybe you are interested in monitoring a third-party network only. You might want your management domain to include devices that are not directly attached to the network on which NNM station resides.

A seed file can also be used to prevent having to manually add devices via the GUI to your management domain. While you can manually add devices from the NNM GUI, it is much less labor-intensive to create a seed file and let NNM do the work. You can also use

loadhosts if you don't want automatic discovery running at all.

If NNM has already discovered the network and you would like to completely undo what's been discovered, you can force re-discovery. This requires removing the NNM databases, configuring the

netmon.lrf file, and restarting netmon. The following steps will allow you to rediscover the network:

Warning

The following steps will remove the all managed devices from the NNM database. Any map customizations you have made will be lost.

1. Create a file named

   seed in the directory

   $OV_CONF . This file can actually reside anywhere (and be called anything), but make sure to reference the exact location in the

   $OV_LRF/netmon.lrf file. Do NOT use environment variables in this file.

2. Modify

   netmon.lrf as shown here by adding the entry after the

   P option. The following entry in

   netmon.lrf is on one line:

3. OVs_YES_START:ovtopmd,pmd,ovwdb:-P

   s /var/opt/

   OV /conf/seed :OVs_WELL_BEHAVED:15:PAUSE::netmon.lrf

4. Execute the

   ovstop command to stop the background processes. (Refer to Section 5.1.4.1, "The Background Processes," for detail on this command.)

   ovstop v

5. Remove the existing NNM database.

   UNIX:

   rm rf $OV_DB/openview

   Windows:

   Select the

   openview directory from the %OV_DB% in Microsoft Explorer and click Delete. Then select

   eventdb from %OV_DB and click Delete.

6. Assuming that your environment variables are set, execute the command to update the configuration file

   ovsuf .

   ovaddobj $OV_LRF/netmon.lrf

7. Execute the command to start NNM background processes.

   ovstart -v

8. Execute the command to monitor background processes.

   ovstatus c

9. Start NNM using the GUI or Dynamic Views and watch the discovery of your network using the seed file.

   ovw&

   OR

   http://hostname:7510

After you start the NNM GUI, drill down to a network submap and watch the network grow as it is being discovered. You may notice that all devices are initially put on segment1 until

netmon receives enough information from SNMP to determine where to place them.

netmon will parse the seed file, retrieve the arp cache of each device listed in the seed file, and start pinging the devices listed in arp cache followed by a series of snmpgets to the devices that responded to ping.

If you decide to implement a seed file after the discovery but want to preserve the devices that have already been discovered, you can skip only step 4, removing the databases. This will maintain existing devices and map customizations in the database and force the discovery of the devices in the seed file.

5.1.4.1 The Background Processes

After installing NNM, the discovery of the network begins. The background processes will automatically start, unless your installation method allows you to specify otherwise. The commands to check, start, and stop these processes are

ovstatus, ovstop , and

ovstart respectively. The "-c" command line switch for

ovstatus lists an abbreviated version of the command output. The output of "

ovstatus c " will look something like this:

Name              PID       State             Last Message(s)
OVsPMD            18958     RUNNING           -
ovwdb             18992     RUNNING           Initialization complete.
ovuispmd          19285     RUNNING           Initialized. 0 ovw clients
registered.
ovtrapd           19206     RUNNING           Initialization complete.
ovactiond         19207     RUNNING           Initialization complete.
ovsessionmgr      18994     RUNNING           Initialization complete.
ovalarmsrv        19208     RUNNING           Initialization complete.
ovdbcheck         18995     RUNNING           Connected to embedded
database.
httpd       -    unknown      (Does not communicate with ovspmd.)
ovtopmd  19205  RUNNING    Connected to native database "openview."
netmon  19286   RUNNING           Initialization complete.
snmpCollect  19287 RUNNING    No values configured for collection.
pmd      18993   RUNNING     Initialization complete.

This is a list of all the NNM background processes. What you see is the process name, the

process ID (PID), the state of the processes, and the last message when the process was started. You want to make sure the process is in a running state. What would cause the process not to be in a running state? If you made an error in

netmon.lrf for example, the netmon process may not start. If you make a simple syntax error in netmon.lrf, you can correct it and restart the individual process by typing

ovstart netmon . If you've destroyed it beyond repair, you can find an original copy in

$OV_NEWCONFIG/OVNNM-RUN/lrf/netmon.lrf .Chapter 8, "Data Collection and Event Configuration."

5.1.5 The netmon.lrf File

The

netmon.lrf file is the configuration file indicating the startup options for the netmon process. The lrf extension indicates that this file is a

Local Registration File (LRF). LRF files are located in $OV_LRF. The first line of

netmon.lrf describes the startup of the netmon processes. See the netmon (1m) manpage for startup options that can be included in the

netmon.lrf file. If you plan to use a seed file, you must modify

netmon.lrf and follow the steps previously discussed.

#
# @(#)netmon.lrf
# @(#)HP OpenView NNM Release B.06.10  Oct 27 1999
# @(#)Copyright (c) 1990-1999 Hewlett-Packard Company
# $Revision: /main/PULSAR/PULSAR_REP/1 $  $Date: 1999/02/02 20:27 UTC $
#
# Local Registration File for Network Node Manager network monitor daemon
#
# Arguments can be placed between the second and third colons
# of the second line.  See lrf(4) and netmon(1m)
#
# Run ovaddobj(1m), ovstop(1m) and ovstart(1m) after modifying this file:
#   ovaddobj $OV_LRF/netmon.lrf
#   ovstop netmon
#   ovstart netmon
#
netmon:netmon:
OVs_YES_START:ovtopmd,pmd,ovwdb:-P s/var/opt/OV/conf/seed:OVs_WELL
_BEHAVED:15:PAUSE:
:netmon.lrf

Note

The following should be on a single line. It is presented on multiple lines here due to the size constraints of this book.

OVs_YES_START:ovtopmd,pmd,ovwdb:-P s /var/opt/OV/conf/seed:OVs_WELL_BEHAVED:15:PAUSE::

Sample netmon.lrf and seed files are available for download from the server http://www.phptr.com/title/0130352098 for both UNIX and Windows systems. Obtain the Readme file for this chapter for a description of the files available and install procedures.