Intelligent Monitor

for

Readme

Version Control

Copyright Notice

Trademarks

Notices

	FLCI000E: Error! Unable to retrieve message from catalog.
	          Ensure the NLSPATH, LC_MESSAGES and LANG environment
	          variables are set correctly.

	LC_CTYPE 
	LC_TIME 
	LC_NUMERIC 
	LC_MONETARY 
	LC_COLLATE 
	LC_MESSAGES 
	LC_ALL 

If any of the previous variables are set, you must remove their setting for the LANG variable to have full effect.

Note:
The NLSPATH variable is used to find the appropriate message catalog directory, as specified by open systems standards. For example, if the message catalogs are in /usr/OV/nls/IMfNetView directory, the NLSPATH variable should begin with the following:

	/usr/OV/nls/IMfNetView/%L/%N.cat

If a message catalog is not found for the desired language, the English C message catalogs are used. As with most current operating systems, localized behavior is obtained by specifying the desired locale. For Tivoli Enterprise software, you set the LANG environment variable to the desired locale name as specified by POSIX, X/Open, or other open systems standards.

NetView for AIX and Solaris

You need to export the following environment variables to complete the configuration of the Intelligent Monitor for Tivoli NetView.

• NLSPATH - /usr/OV/nls/IMfNetView/%L/%N.cat
• TISDIR - /usr/OV/nls - this is the parent of the 'codeset' directory for this installation.

NetView for Windows

You need to go to Start, Settings, Control Panel and double-click on System. Select the 'Advanced' tab, then select the 'Environment Variables' button, this will bring up the Environment Variables dialog. Define or add to the following environment variables for your installation.

• NLSPATH - %NV_DRIVE%\usr\ov\nls\IMfNetView\%L\%N.cat
• TISDIR - %NV_DRIVE%\usr\ov\nls - this is the parent of the 'codeset' directory for this installation.

In Western European languages, the translated output of Tivoli commands on Microsoft®. Windows operating systems is encoded using the Windows 1252 code page. To view this text correctly in a DOS command window, perform the following.

	chcp 1252

Set the font for that window to Lucida Console in the properties, font tab for that window.

Adapter Configuration

This section applies to all platforms.

Edit the file /usr/OV/conf/topxlistener.properties.

Replace localhost in these lines,

   transport.local.ip.address = localhost
   transport.request.address  = localhost.BASETEST.QM+BASETEST.Q
   transport.response.address = localhost.BASETEST.QM+BASETEST.Q

with the local IP hostname. For instance for kiwi.tivoli.com you would edit as,

   transport.local.ip.address = kiwi.tivoli.com
   transport.request.address  = kiwi.tivoli.com.BASETEST.QM+BASETEST.Q
   transport.response.address = kiwi.tivoli.com.BASETEST.QM+BASETEST.Q

Replace localhost in the following line,

    transport.server.ip.address  = localhost

with the IP hostname of the TBSM machine with the CommonListener, for example,

    transport.server.ip.address  = tbsm.tivoli.com

Edit /usr/OV/conf/nvid.conf

This file contains information about the NetView site.  This information will allow multiple NetView sites to contribute data to a central TBSM database.

NVID	This site identifier is reserved for future use by NetView.  It can be used as a label for the network management site. Limited to 15 chars, no spaces.
NetworkID	This site identifier is appended to all instid's of the TBSM objects to uniquely identify objects from each site.  Typically it is shorter than NVID and is intended to be used by cooperating applications communicating with TBSM.  Limited to the alphanumeric character set  (A-Z, a-z, 0-9, no spaces).
PrimaryURL	this is the IP hostname and port for the web server on this node, e.g. kiwi.tivoli.com:8080.  This is used when launching the NetView Web Console from the TBSM Java Console.
secondaryURL	This is an optional backup NetView machine that shares the same nvid.conf file

The nvid.conf file should be identical on both the primary and secondary Tivoli NetView server machines.

Edit the file /usr/OV/conf/topxtbsmagent.properties

This will affect the behavior of the tbsmadapter. The property listenerlog=true will cause an XML dump into /usr/OV/log/BaseClientLogging.log instead of passing it to the remote TBSM machine.  The normal operation is 'false' which will cause data to pass to the CommonListener .

Edit the file /usr/OV/conf/topxtrapgate.conf.

Comment out any events you do not want the adapter to send to TBSM.

Console Launch Capability

Console Launch on TBSM

1. On the TBSM database server on NT, find the following files in the \tivolimanager directory.  They are already installed under the applicable directory,

bin\nvlaunchconfig.sh

sql\netviewlaunch.upg

sql\LookupNetviewURLs.sqi

sql\_LookupNetviewURLs.sql

2.  Edit the file nvlaunchconfig.sh and replace the XXXXX’s  with the TBSM database server name, SQL Server username and password.

3. Find the stored procedure and menu items and install them by running the ApplyUpgrade script,

cd \tivolimanager\sql

sh ./ApplyUpgrade netviewlaunch.upg

Installation of NetView Web Console

Install the NetView Web Console as per Tivoli NetView Installation instructions.

Special instructions for Unix

Use the nvwc_aix_jre_1.3.tar file to install the NetView Web Console. This includes the JRE. This file is found on the NetView server in,

/usr/OV/www/wwwroot/download/nvwc_aix_jre_1.3.tar

Create the environment variable NVWC_HOME to define the directory you installed the NetView Console in. Under this will be the bin and lib directories.

Make sure the NVWC_HOME environment variable is always defined by placing it in the .profile or other such file.

Edit the file $NVWC_HOME/bin/nvlaunch.sh to set the path for the Java 1.3 runtime executable. Find the line near the top,

NVWC=$(dirname $0)/..

and add the following line underneath it,

export PATH=$NVWC/jre/bin:$PATH

Launch Patch for v7.1

This is a mandatory patch for the NetView Web Console running with the TBSM Console.  It consists of the file launch.jar which can be used on both AIX and Windows platforms.  It should be placed in,

Windows

%NVWC_HOME%\lib\launch.jar

Unix

$NVWC_HOME/lib/launch.jar

Post-Installation Check

Check that these components are running,

• Tbsmadapter daemon
• netviewd daemon, or the GUI on the NetView server, and the network has been discovered
• Tbsmtopo and tbsmtrap processes on the NetView server (started automatically with the GUI or netviewd)
• CommonListener service on TBSM server

Perform a bulk upload, as described in the User Guide below.  Then check that

NetView IP data has been uploaded to TBSM

• Ensure TBSM server including the TBSM CommonListener service is running.
• Ensure Tivoli NetView is running and the network is discovered
• Ensure the TBSM Adapter for Tivoli NetView is installed and running on the NetView server
• Invoke the Upload function (see the Adapter documentation for more details)

TBSM Console can view the IP data

• Ensure that the TBSM Console is running and can view the IP data
• Restart the TBSM Console after you finish setting up the launch menu items below

NetView Web Console

• Ensure the Web Console accounts have been configured on the NetView server with users, roles and passwords
• Ensure NetView's Web Console can connect to the NetView server using one of these accounts

Operating the Intelligent Monitor for NetView

1. Start the daemons (this will also start the tbsmadapter daemon) and the NetView GUI.  The Intelligent Monitor for NetView contains TBSM's common listener adapter and two other programs, they are:
1. the daemon tbsmadapter,
2. ovw registered application tbsmtopo,
3. ovw registered application tbsmtrap.

The last two start automatically with the NetView GUI.

ovstart

netview

2. To initiate an upload of all the NetView objects to TBSM from the NetView menu, select,
   
    Tools->TBSM Adapter Manager: Bulk Upload
   
3. Events generated by NetView that are configured in topxtrapgate.conf will be sent to TBSM via the CommonListener  automatically.

Intelligent Monitor for NetView Output

The adapter will send the IP objects and events to the CommonListener  in XML format.  There are several useful logging and tracing files,

/usr/OV/log/BaseClientTrace.log	tracing from the local adapter transport code (tbsmadapter)
/usr/OV/log/tbsma.log	logging from the local adapter code (tbsmadapter)
/usr/OV/log/tbsmatopo.log	logging from tbsmtopo process
/usr/OV/log/tbsmatrap.log	logging from tbsmtrap process
/usr/OV/log/BaseClientLogging.log	XML output when listenerlog=true in topxtbsmagent.properties
/usr/OV/log/tbsmatrace.log	creating the file /usr/OV/log/tbsmatrace.trigger will cause tbsmtopo to begin tracing to this file

Other documents describe the data model in detail. These are the IP objects created in TBSM.

These objects are visible in TBSM Java Console:

• IPNetwork  -- Top level object for all IP objects
• NetworkLocation
• NetworkSubnet
• NetworkSegment
• NetworkRouter
• NetworkHub
• NetworkSwitch
• NetworkBridge
• NetworkNode
• NetworkPC
• NetworkUnix
• NTServer
• NetworkInterface
• Service

Other objects created in the TBSM database, but not visible via the Console for this release:

• NetViewDistributed -- contains data from nvid.conf
• NetViewNetworkObject -- one for each node - contains an extended set of attributes

User Guide

Intelligent Monitor for Tivoli NetView

TBSM is initially populated with IP topology data from NetView.  This is achieved via a Bulk Upload initiated from a user command on the NetView server.  This data includes all the managed objects, subnets, and segments, plus information identifying which NetView server the objects came from.

Thereafter, each NetView server will maintain its own data in TBSM. This is referred to as 'Delta Upload'. When an object is added, deleted, or its attributes change, NetView will notify TBSM via the TBSM Adapter for NetView in the form of a TBSM event and update the object data, adding or deleting objects as necessary. 

For instance,

• when the status of a router is changed, a TBSM event for the new interface status will be sent to TBSM.  TBSM will be responsible for propagating that status up the hierarchy.
• When a new router is discovered, NetView will create new TBSM objects for the router, the interfaces, and any new segments and subnets, and populate those objects via the TBSM Common Listener. 

If the TBSM server is unavailable or down, then the data is transparently queued at the NetView site until communication is restored.  The data remains queued even if  the NetView server is subsequently recycled.

If the TBSM CommonListener service is not running, then the data is transparently queued at the TBSM server machine.

To Invoke a Bulk Upload

From the NetView Console (read-write map):

     Tools->TBSM Adapter Manager: Bulk Upload

From the command line (this is necessary if the NetView daemon (netviewd) is running):

Unix:

     /usr/OV/bin/tbsmbulkupload.ksh

Windows:

     \usr\ov\bin\tbsmbulkupload.bat

The user can invoke a Bulk Upload initially, and then on demand, to resynchronize with a subsequent bulk upload after any of the adapter processes have not been running.

Multiple NetView Management Sources

This section will help you understand how to set up multiple NetView feeds to achieve the desired result in TBSM.

What is supported:

• Multiple NetView sites around the world managing the enterprise's network under a single TBSM hierarchy
• Each NetView site may consist of two NetView machines in a failover configuration
• Each NetView site manages a subsection of the total network, and TBSM needs to handle duplicate IP addresses (e.g. 10.*.*.* type networks) and possible duplicate object names across the entire network.  Some of these will represent the same overlapping object; some will be different objects.
• Each NetView site must maintain and refresh their objects in TBSM.

The key elements for site and instrumentation identification that satisfy these requirements are,

NVID

• Defined in /usr/OV/conf/nvid.conf. 
• The NVID property must be unique to each NetView server or failover pair.  The NVID must be 15, or fewer, characters with no spaces. 
• It may be descriptive of the NetView site, e.g., "Boston", "MainTrunk", "Customer_Site", etc.
• It must be shared with a redundant NetView managing the same network.

NetworkID

• Defined in /usr/OV/conf/nvid.conf. 
• The networkID property must be unique to the NetView server’s management site.
• It is appended to all object names so should be kept short. 
• This value can be used by other management applications such as Tivoli Event Console.

InstrumentationID

• Used by the CommonListener to identify the data source, in this case, NetView.
• The TBSM adapter for NetView creates this id by concatenating the string "TBSM Instrumentation for Distributed NetView - " with the NVID value.
• The CommonListener tags each object with the InstrumentationID. This defines the set of objects to be refreshed by a bulk upload.  Note that a bulk upload updates existing objects in its set, adds any new objects, and deletes objects that were not present in the bulk upload. 

TBSM table object.CL_AutoPlacement

• This table is used by the CommonListener  to map instrumentations (data sources) with a top level Enterprise. 
• The _in column is a LIKE clause for matching against the InstrumentationID. 
• The  _out column is the name of the Enterprise object that this instrumentation is feeding.

Typically all the NetView sources will upload IP data for one TBSM Enterprise, but each individual NetView's objects will be differentiated by the networkID defined in the nvid.conf file.

Launching NetView Console from TBSM

From the TBSM Java Console, users can select a host machine managed by NetView and then right-click to select a launch menu item from the main Launch menu.  Each of the menu items will launch to a NetView Web Console running on the same machine.  Menus are context sensitive, so they will only contain active menu items appropriate for the selected object.

The following menu items are available,

Launch->NetView Web Console

Displays the NetView Submap Explorer showing the object in focus on a topology map.  This menu item will appear for all host type objects.

Launch->NetView Diagnostics

Displays the Diagnostics dialog for the object selected, allowing the operator to perform any of the diagnostic functions available from NetView. This menu item will appear for all host type objects.

Launch->NetView Object Properties

Displays the Object Properties dialog for the object in focus.  This menu item will appear for all host type objects.

Note that a separate NetView Web Console will be launched for each different NetView server.  So, if three NetView servers contribute to TBSM, there will be up to three separate NetView Web Consoles active.  The result of selecting the Launch menu items will be to either start a new NetView Web Console if none is yet connected to that server, or to change the context of the active NetView Web Console already connected to that server.  Context is defined as the function plus the object in focus.

Appendix

Behind the Scenes

The Intelligent Monitor for Tivoli NetView consists of three conceptual components.  At present these are three separate programs that reside on the NetView server and together form the Adapter.

tbsmadapter daemon

This daemon maintains a connection with the TBSM Common Listener.  The tbsmadapter daemon is a Java application responsible for packaging the data and sending it to the remote TBSM Common Listener. 

tbsmtopo OVW application

This application is invoked as part of the NetView native console (and the netviewd daemon).  In the case of multiple NetView native consoles running, only one instance will be connected to the tbsmadapter daemon.  This application is responsible for handling requests to extract the data from NetView's databases and package it as XML prior to delivering it to the tbsmadapter daemon. 

tbsmtrap OVW application

This application is also invoked as part of the NetView native console.  It will listen for all traps and generate TBSM event messages for the appropriate object. For topology change NetView traps it will generate TBSM event messages and, as appropriate, it will signal "tbsmtopo" to generate a delta discovery, or delete, of the NetView object to send to TBSM.  The set of events "tbsmtrap" listens for is controlled by the file topxtrapgate.conf.  Note that when netviewd is running, you can use the commandline utility, tbsmupbulkupload.bat (.ksh) to invoke a Bulk Upload.

The remote TBSM CommonListener is part of the TBSM product and is responsible for creating, deleting, and updating the TBSM objects from a variety of product sources.

Restrictions

• It is expected that the NetView server will be running with the netviewd console daemon.  This daemon should use the default map and not be used with any other map.  However the Intelligent Monitor for Tivoli NetView will work with either the native GUI console or the netviewd daemon.
• You can mark objects on the map Hidden to avoid uploading them to TBSM.
• Unmanaged subnet objects will be created in TBSM, but no object underneath an unmanaged object will be created.  This includes interfaces on routers in those subnets, even if the interfaces are managed.