SNMP Agent and HP Openview

SNMP Agent and HP Openview

1. SNMP Details

SNMP manager and agent communicate through UDP port 161. SNMP trap receiver listens to UDP port 162 for TRAP messages.

Message format for SNMPv1 and SNMPv2 GET, GET response, GET NEXT and SET; and SNMPv2 TRAP and INFORM is shown below:

Version

Community

PDU

PDU
PDU Type	Request ID	Error Status	Error Index	Variable Bindings

SNMPv2 GET BULK PDU format is different.

PDU (GET BULK)
PDU Type	Request ID	Non repeaters	Max Repetitions	Variable Bindings

Non repeaters specifies the number of supplied variables that should not be iterated over.

Max Repetitions specifies the maximum number of iterations over the repeating variables.

PDU Type:

• GET: A0
• GET NEXT: A1
• GET response: A2
• SET: A3
• TRAP (v1): A4:
• GET BULK (v2): A5
• INFORM (v2): A6
• TRAP (V2): A7

The encoding of SNMP messages follows the Basic Encoding Rules (BER). BER is part of ASN.1 standard. All SNMP messages follows the tag-length-value structure. The following graph shows the tag value.

0x30 - sequence

tag

length

value : sequence of fields

0x02 - integer

tag

length

value : 0 (SNMPv1)

version

0x04 - octet string

tag

length

value : octets

community string

tag - depends on PDU

tag

length

value : sequence of fields

SNMPv1 PDU

In SNMP v1, SNMP GET operation is atomic, either all the values are retrieved or none of them are. SNMP SET operation is atomic too, either all the values are set or none of them are. SNMPv2 extends the SNMP protocol by defining:

• an SNMPv2 TRAP PDU
• an Inform message, which is basically a TRAP that gets ack
• a GET-BULK message,which is a souped up extension to GET-NEXT
• additional error status
• changes the way responses to GET and GET-NEXT are handled if one of the objects in the variable bindings cannot be retrieved.

SNMPV2 GET and GET-NEXT will return the object values that are available, even if some object values cannot be retrieved. SNMPv2 SET operation is still atomic.

SMIv2 introduces textual conventions. Textual conventions are refinements of basic data types. and textual conventions resolve to primitive data types. Example:

MacAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1x:"
    STATUS       current
    DESCRIPTION
                 "..omitted..."
    SYNTAX       OCTET STRING (SIZE (6))

1.1 SNMPv1 TRAP

The SNMPv1 PDU format is shown below:

PDU Type

0xA4

ent.

addr

generic

specific

ts

vb

Some real case PDU formats in hexadecimal format is shown here:

Cold Start generic trap:

Sequence          30 82 00 21
Version           02 01 00
Community         04 06 70 75 62 6C 69 63
PDU Type          A4 14             (A4 is PDU type of SNMPv1 TRAP)
enterprise        06 01 00
agent address     40 04 0A 3E 55 00 (agent generating the trap)
generic           02 01 00          (00 is cold start)
specific          02 01 00          (00 means no specific trap)
time-stamp        43 01 02
variable bindings 30 00

Customised specific trap:

Sequence          30 82 00 2A
Version           02 01 00
Community         04 06 70 75 62 6C 69 63
PDU Type          A4 1D             (A4 is PDU type of SNMPv1 TRAP)
enterprise        06 0A 2B 06 01 04 01 E4 44 01 02 01
                        (1.3.6.1.4.1.xxxxx.1.2.1 is the ObjectID of the TRAP)
agent address     40 04 0A 3E 55 00 (agent generating the trap)
generic           02 01 06          (06 means enterprise specific)
specific          02 01 01          (01 is the number of specific TRAP)
time-stamp        43 01 09
variable bindings 30 00

2. SNMP Agent

An SNMP agent(agent) responds to SNMP requests, which are sent from SNMP manager application(manager). At the same time, an agent sends out SNMP TRAP messages to manager when pre-defined conditions has been reached.

The design of agent can be divided into three functional areas:

• transport stack
• protocol engine
• access to management information

There are two approaches when it comes to designing agent:

• monolithic approach - where the transport stack, protocol engine and management info access are combined together.
• extensible approach - where the agent and management info access are separated, the linkage of agent and management info access are delayed until load time or run time.

For the extensible agent approach, there are a few implementations:

• SMUX in RFC 1227 - SNMP multiplexing protocol
• SNMP-DPI in RFC 1228 and RFC 1592 - SNMP Distributed Protocal Interface
• AgentX in RFC 2741 and RFC 2742
• EMANATE technology from SNMP Research

There are some open source APIs available on the internet.

• SNMP++ - a set of C++ classes for writing manager
• AGENT++ - a set of C++ classes for writing agent
• NET-SNMP - a set of C APIs for writing manager and agent

2.1 Using AGENT++ to write an agent

AGENT++ v3.5.6 and SNMP++ v3.2.1 will be used in this project. SNMP++ is a set of C++ classes that contains the SNMP protocal engine. For transport stacks, SNMP++ makes use of the Windows socket library or Linux socket library calls. AGENT++ extends SNMP++ by providing the access methods to management information that an agent needs.

AGENT++ is a set of C++ classes which provides a complete protocol engine and dispatch table for the development of SNMP agents. AGENT++ is a multilingual API which supports SNMPv1, SNMPv2c, and SNMPv3. It provides various C++ classes implementing prototypes for scalar and table SNMP managed objects that can be customized by derivation. Additional classes support the development of proxy agents as well as sending notifications.

At the same time, AgentGen v1.8.6 is used. It is a tool to generate C++ source code from SNMP MIB files. The generated code makes used of the AGENT++ library, and thus cannot be compiled without it.

AgentGen Code Generation Steps:

1. cd to agentgen directory
2. % mkdir mibrepository
   mibrepository is a directory for storing compiled MIB files in intermediate format
3. % agentgen ../mibrepository init
   initialise the repository
4. % agentgen ../mibrepository load miblist.txt
   load a list of MIB files to the repository
5. % agentgen ../mibrepository add sir-line-mib.txt
   add a single MIB file to the repository
6. % agentgen ../mibrepository generate SIR-LINE-MIB h 3.5 > /home/sir_line_mib.h
   generate a header file, using AGENT++ v3.5
7. % agentgen ../mibrepository generate SIR-LINE-MIB c 3.5 > /home/sir_line_mib.cpp
   generate a implementation file, using AGENT++ v3.5

The generated code from AgentGen v1.8.6 is guaranteed to work with AGENT++ v3.5.6 and SNMP++ v3.2.1. There is no such guarantee on the generated code from other lower/earlier AgentGen version.

SNMP Agent Compilation Procedure with MSVC++ 6.0 on W2000:

• Compile SNMP++ library
  • modify config.h to comment out _SNMPv3 definition
• Compile AGENT++ library
• Create a new project
• Set up VC++ include path
  • Tools->Options
  • put in AGENT++ and SNMP++ include path(must put them above standard VC++ include path)
• Add in library modules
  • Project->Settings->Link Tab
  • add in snmp++.lib, agent++.lib, wsock32.lib for debug version
  • add in snmp++.lib, agent++.lib, wsock32.lib, and libc.lib and msvcrt.lib for release version
• Setup Vc++ library path
  • Tools->Options
  • put in AGENT++ and SNMP++ lib path(any order)
• Build the project
• If there is LNK4098 warning, goto
  • Project->Settings->Link Tab
  • In Project Options: add in /verbose:lib to determine which libraries the linker is searching
  • add in /nodefaultlib:"libcd.lib" to ignore the specific library
• If SNMP agent cannot execute, goto
  • Control Panel->Administrative Tools->Services and stop the SNMP Service(It is because the SNMP Service uses UDP port 161, same as SNMP agent, therefore SNMP agent cannot bind the same port again.)

3. HP Openview

HP Openview is a complete portfolio of software solutions and services. It covers a broad area of management topics, including:

• Network/Internet Management
  • Network Node Manager (NNM)
  • NNM Extended Topology
  • NNM Multicast
  • Performance Insight for Networks
  • Problem Diagnosis
  • Smart Plug-ins (SPIs) for Data Network Devices
  • TeMIP
  • Trend Performance manager
• Systems Management
  • Advanced Security
  • GlancePlus
  • Operations for UNIX/Windows
  • System SPIs
  • Performance (Manager, Monitor, Agents)
• Application Management
  • Integration Tools
  • Internet Services
  • Application SPIs
  • Web Transaction Observer
• Storage and Data Management
  • Data Protector
  • Omniback II
  • Storage Area Manager
• Customer Service Management
  • Reporter
  • Service Activator
  • Service Desk
  • Service Navigator
• Service Usage Management
  • Dynamic Netvalue Analyzer
  • Internet Usage Manager

Network Node Manager

HP Openview Network Node Manager (NNM) is the focus of this discussion. It features:

• visual display of the network - map symbols change color to indicate if something is wrong
• data collection of critical network information - this data can be graphed in real-time.
• event handling - events are sent to NNM's event browser
• remote access via the web
• provide troubleshooting tools to help users resolve problems
• maintains a relational database - data can be exported for historical analysis using any choice of statistical programs
• out of the box reports on the health of the network - provides easy access to report generation

NNM Maps and Submaps

Maps

A map is a collection of OpenView Windows (OVW) objects and their relationships. Users don't view maps directly. They view windows called submaps that display a subset of map information. Users can create several maps, among all the maps that might exist, users can select one map to be the open map. The open map is the only map that can be updated. Only one map can be open at a time in any given OVW session.

Submaps

A submap is a collection of related symbols that are displayed in one graphical window. Submaps essentially provide a view into the map object space. Each submap displays a different perspective of the information in the map, with the submaps typically organized in a hierarchical fashion.

The most common method for users to navigate through submaps is double-clicking on explodable symbols. Double-clicking on an explodable symbol will cause a submap to be displayed, if one exists. This submap is called the child submap. The object associated with the explodable symbol is called the parent object. The child submap shows all the objects contained within the parent object. The submap on which the parent object is represented is called the parent submap.

Submap context provides a way for application developers to describe the intended use for the submap. This context is then used to selectively add and remove menu items for the submap.

eg. Map->Submap->Properties, Context Tab,
    isInternet
    isIP

When a developer uses the application registration files to customize a menu, the developer defines a menu placement rule that specifies the contexts in which the menu item can be placed. When a submap is opened, the full list of possible menu items is checked. If a menu item's placement rule evaluates as true for the given submap's context, it is added to that submap's menus.

Here is a diagram of the relationship between maps and submaps.

In the diagram, submap 1 is the root submap for the map. Submaps 3A and 3B are child submaps of the objects whose symbols appear in submap 3. Submap 2 is an orphaned submap. Each submap contains symbols that represent objects on the map. The map is a collection of objects and their relationships, and submaps are the vehicle by which this map information is displayed.

NNM Objects and Fields

In NNM, fields are object attributes stored in the HP OpenView Windows (OVW) object database. Fields are the building blocks from which objects are constructed. Fields are created using either the field registration file (FRF) or the programming way.

Each field definition is uniquely identified by a field ID. Fields can contain a single data element, or they can contain a list of data elements of the same type.

By themselves, fields are not very useful. Only after a field is associated with an object can you perform the real manipulation of data, such as setting or retrieving field values. Fields can contain data only when they are associated with objects.

In NNM, an object is an internal representation of a logical or physical entity or resource that exists somewhere in a computer network. An NNM object consists of a unique object identifier and a set of fields that specify all the characteristics of the object.

The OVW object database manages all object and field information. All OVW maps use the same object database. The object database is implemented as a stand-alone module that works in conjunction with the rest of OVW. Entries in the OVW object database persist across OVW sessions. Fields and objects created in one OVW session are available to all other applications in all OVW sessions.

NNM Symbols

Symbols are presentation elements, while objects are underlying database elements that represent real-world objects. A symbol is a graphical representation of an object as it appears on a submap of a particular map. An object may be represented by multiple symbols. As presentation elements, symbols have attributes that are unrelated to the objects they represent. Important symbol attributes include:

• label : The symbol label is a textual string that is displayed at the bottom of each symbol. The symbol label is provided as a convenience to users. The label does not have to be unique.
• symbol type : The symbol type determines the graphical representation of the symbol. The term symbol type is a convenient way of referring to the symbol class/subclass pair that defines how the symbol is displayed.
• behavior : A symbol can either be explodable or executable. This characteristic determines what will happen when the user double-clicks on the symbol. By default, symbols added to a map are explodable in nature. That is, double clicking on an explodable symbol results in the display of the child submap. Applications and users can make a symbol executable. Double clicking on an executable symbol results in the invocation of an action provided by an application.
• position : The submap layout algorithm controls how symbols are placed on a submap. The layout algorithm is chosen during submap creation, and is fixed for the life of the submap.
• status : Each symbol within NNM can display status information through the use of color. Each of the different possible status values has an associated color that indicates the status of the symbol.
• status source : symbols can receive status from one of three sources:
  • Status by Object: This status source causes the symbol to reflect the status for the underlying object.
  • Compound Status: This status source can be used for a symbol whose underlying object serves as a parent object for a child submap.
  • Status by Symbol: This status source lets a specific symbol instance receive status directly from an application. Use this status source if the application has the exclusive responsibility for setting status for the specific symbol instance.
• presentation : Symbol presentation provides visual cues to emphasize or to de-emphasize a symbol.

NNM Services

There are two types of services in the operation of NNM:

• Background services that run continuously independent of whether ovw is running.
• Foreground services that run while ovw is running.

NNM background services:

The following services and files are involved with the startup of NNM.

• ovstart: Starts the various services that make up the NNM.
• ovspmd: Launches and manages all background services. ovspmd interacts with the user commands ovstart, ovstop, ovstatus, ovpause, and ovresume, and performs the appropriate actions on the background services.
• ovsuf: Contains the configuration information for ovspmd. Each entry in ovsuf is created by ovaddobj from information in the LRF (Local Registration File).

The following services run in the background during regular operation.

• netmon: Polls SNMP agents to discover your network, and then detects topology, configuration, and status changes in the network.
• ovactiond: Receives events from pmd and executes commands.
• ovalarmsrv: Provides event information to Java-based Alarm Browsers.
• ovcapsd: Listens for new nodes and checks them for remote DMI capabilities, web-manageability, and web server capabilities.
• ovhpas: Maintains topology and node status information for NNM Dynamic views.
• ovrequestd: Executes the reports and data warehouse exports according to a predefined schedule. Once a report is configured, ovrequestd starts executing the exports and the reports.
• ovsessionmgr: Manages users' web sessions. ovsessionmgr.exe is started by ovstart.
• ovtopmd: Maintains the network topology database. The topology database is a set of files that stores netmon polling status and information about network objects, including their relationships and status. ovtopmd reads the topology database at start-up.
• ovtrapd: Receives SNMP traps and forwards them to pmd. ovtrapd also responds to SNMPv2 requests.
• ovuispmd: Manages the NNM user interface services and distributes relevant ovspmd requests to each instance of ovw that is running. ovuispmd must be running for ovw to be started, and should be running whenever ovspmd is running.
• ovwdb: Controls the object database. The object database stores semantic information about objects.
• pmd: Receives and forwards events, and logs events to the event database. pmd also forwards events from the network to other applications that have connected to pmd using the SNMP API.
• snmpCollect: Collects MIB data and performs threshold monitoring. snmpCollect stores the data it collects in the install_dir\databases\snmpcollect directory and sends threshold events to pmd.

Foreground Services

This section describes the NNM foreground services that may be running after you execute ovw.

• ipmap: Runs under ovw to automatically draw IPX and IP topology maps representing your network.
• ovw: The service that provides map drawing, map editing, and menu management. When you start the OVW services by executing the ovw command, ovw automatically invokes ipmap, xnmevents, and the other applications, which register to be started by ovw.
• xnmappmon: The Application Encapsulator that displays textual results of monitoring operations for managed SNMP objects selected from the map.
• xnmbrowser: The Tools:SNMP MIB Browser menu item that enables you to get and set MIB values for Internet-standard and enterprise-specific MIB objects.
• xnmbuilder: The Options:MIB Application Builder:SNMP menu item that enables you to build custom screens to manage multivendor MIB objects. The information you define using the MIB Application Builder is stored in registration files and help files using mibform, mibtable, and xnmgraph.
• xnmcollect: The Options:Data Collection & Thresholds:SNMP menu item that enables you to configure snmpCollect to collect MIB data from network objects at regular, configurable intervals. The configuration information is stored in the install_dir\conf\snmpCol.conf and snmpRep.conf configuration files. The collected data are stored in files in the install_dir\databases\snmpCollect directory.

• xnmevents: The alarm browser that is automatically invoked by ovw to display events that are being received by pmd. xnmevents reads the install_dir\log\xnmevents.username.map file only at start-up for events that occurred since the last time xnmevents was run. xnmevents reads the event database only at start-up to obtain those pending events. xnmevents also reads trapd.conf to obtain information about how to customize event messages.
• xnmgraph: The tool that enables you to graph the results of monitoring operations for managed SNMP objects selected from the map. The results may be real-time or collected historical data.
• xnmloadmib: The Options:Load/Unload MIBs:SNMP menu item used to load new Internet-standard or enterprise-specific MIBs into the loaded MIB database.
• xnmpolling: The Options:Network Polling Configuration->IP/IPX menu item that updates the polling configuration.
• xnmsnmpconf: The Options:SNMP Configuration menu item that enables you to add, delete, and modify SNMP configuration parameters and the netmon status polling interval. The SNMP configuration parameters include community name, set community name, timeout interval, number of retries, and proxy information.
• xnmtrap: The event configurator invoked by the Options:Event Configuration menu item that enables you to define enterprise-specific events (traps). You can customize the alarm message displayed through xnmevents when a particular event arrives. You can also specify a command or a batch file that should be executed when a particular event arrives. Event configuration changes are stored in the install_dir\conf\C\trapd.conf configuration file.

Web CGI Programs: The following programs are CGIs, which access HP OpenView's web applications.

• jovw.exe: Starts the Network Presenter.
• nnmRptConfig.exe: Launches the Report Configuration interface.
• nnmRptPresenter.exe: Launches the Report Presenter.
• ovalarm.exe: Launches the Alarm Browser user interface.
• ovlaunch.exe: Launches the HP OpenView Launcher and opens the user login screen, when UserLogin is set.
• snmpviewer.exe: Launches the SNMP Data Presenter, or displays textual or graphical results of SNMP monitoring operations on your browser.

Here is a diagram that shows the interaction among NNM services.

NNM's Event System

Background processes within NNM gather information and generate events that are forwarded to NNM. Events can also be emitted from agents on managed nodes. Unsolicited SNMP events or notifications are called traps. NNM provides one centralized location, the Alarm Browser, where the events and traps are visible to the users. It can be controlled which events and traps are considered important enough to show up as alarms. The users can easily monitor the posted alarms and take appropriate action to preserve the health of your network.

All events are passed to NNM's pmd service, which then logs them in the event database and sends them on to all applications that subscribe to them. For example, the Alarm Browser subscribes to all events configured to display in a category of the Alarm Browser.

If additional actions were configured to automatically execute upon the pmd services's receipt of a certain alarm (such as dialing a pager or sending an email message), the alarm is also forwarded to NNM's ovactiond service.

Here is a diagram that shows the interaction of pmd service to other services.

All events are entered into the event database. The most important ones are posted to the Alarm Browser. Many NNM services rely upon the information stored in the event database. The default maximum size setting is 16MB. The event database is divided into four files. In the default configuration of 16MB, this means that each file has a maximum size of 4MB. When all four files are full, the oldest log is truncated and new events are written into the reclaimed space.

We can change the amount of disk space that is reserved on the management station for the event database by setting the b parameter in the pmd.lrf file. Information from the event database can be archived into the data warehouse for trend analysis by selecting the menu item

Tools:Data Warehouse->Export Events

Events that are configured to post as alarms in the Alarm Browser are sent to the Alarm Browser's state file. The contents of this state file provides the starting point for displayed alarms, each time you open the NNM interface. The state file maintains all user edits to the alarm list, such as acknowledgments or deletes. The number of alarms being stored and displayed can be modified. The file that controls the alarm browser setting is ovalarmsrv.lrf.

The NNM data warehouse is a relational database (RDBMS) provided with NNM. NNM stores a copy of the information from the NNM operational databases into the data warehouse. The data warehouse information is accessible with standard SQL statements using ODBC tools. The information in the NNM event database is discarded when a certain volume is reached. Information copied to the data warehouse is retained for as long as we wish. The limit to the size of the data warehouse is up to us.

Here's a picture that shows the relationship between the event database and data warehouse.

Event Correlation System (ECS)

Event correlation modifies the flow of events by recognizing patterns of redundant events and either discarding them or replacing them with fewer more meaningful events. Event correlation can dramatically reduce the number of and improve the value of events displayed in your Alarm Browser. Instead of displaying the whole event storm typically generated by equipment and link failures, a correlated event stream displays only the most meaningful alarms, resulting in faster and easier identification of network problems.

Integration with NNM

There are many ways for an application to intergate with NNM. The fundamental integration covers three points of integration:

• menu level integration - by application registration files (ARFs)
• custom traps and trap categories - defined in event config file trapd.conf, and supplying third party MIB file
• custom icons - supplying the GIF file and specifying it in the ARFs

HP Openview NNM SDK

NNM SDK is used to build NNM applications. NNM applications is used to be integrated into NNM, using ARFs. It consists of the following:

1. library files
2. include files
3. program samples
4. SDK documentation

Device Symbol

NNM determines which node symbol to be used for each node by referencing two configuration files:

install_dir\conf\oid_to_sym
install_dir\conf\oid_to_type

oid_to_sym: provides NNM with a mapping from system.sysObjectId to default symbol class and type

oid_to_type: provides NNM with a mapping from system.sysObjectId to object type

As an example, the procedure for changing device symbol for a particular device is listed here.

1. Create new symbol registration file named install_dir\symbols\C\Computer\MY700

   
   symbolType "Computer" : "MY700"
   {
    Filebase "my700";
    CursorSize 38;
    Capabilities
    {
     isMY700 = 1;
    }
   }
   
   
   

2. Create symbol graphics - create a set of GIF files to provide multiple sizes of the same graphic

   
   install_dir\www\htdocs\bitmaps\C\computer\my700.16.gif
   install_dir\www\htdocs\bitmaps\C\computer\my700.20.gif
   
   install_dir\www\htdocs\bitmaps\C\computer\my700.32.gif
   install_dir\www\htdocs\bitmaps\C\computer\my700.26.gif
   install_dir\www\htdocs\bitmaps\C\computer\my700.38.gif
   
   
   install_dir\www\htdocs\bitmaps\C\computer\my700.44.gif
   
   
   install_dir\www\htdocs\bitmaps\C\computer\my700.50.gif
   

   and copy the new GIF files to this directory install_dir\bitmaps\C\computer (for NNM on management station)
3. Map sysObjectID to new symbol - Edit the file install_dir\conf\oid_to_sym

   1.3.6.1.4.1.311.1.1.3.1.2:Computer:MY700
   

4. Create field registration file install_dir\fields\C\MY700

   
   Field "isMY700"
   {
    Type Boolean;
    Flags Capability;
   }
   
   
   

5. Inform NNM about the new fields

   
   Open a command prompt
   
   1)ovw -fields (inform NNM of the new field)
   
   2)ovw -verify (verify for syntax errors)
   
   
   

6. Provide additional information in oid_to_type file (HP sysObjectID is located in HPoid2type file)
7. 
   
8. Update the database (so new symbols appear on map)

   
   ovstop -c -v netmon
   
   (shutdown just the netmon service)
   
   ovtopofix -u -o 1.3.6.1.4.1.311.1.1.3.1.2 2>&1 | more
   
   (update the database, same sysObjectID as used in oid_to_sym file)
   ovstart -v
   (restart netmon service)
   ovstatus -c
   
   
   (check the services are running)
   

9. Verify symbol change is in place
   
   
   
   
   Firstly, execute NNM, observe console pop-up window, locate MY700 symbol type 
   Secondly, locate MY700 symbol type
   
   
   
   

   
   1)Edit: Find->Object by Symbol Type
     In the Find by Type dialog box, select the computer class
     Select the MY700 symbol subclass
   2)Edit: Find->Object by Attribute
     Scroll through to select 'SNMP sysObjectID'
     Select Exact Match for type of string search
     Enter the sysObjectID for MY700 at the Complete String field
     eg.  .1.3.6.1.4.1.311.1.1.3.1.2
   
   

Object's Vendor and SNMP Agent Field

NNM automatically discovers all IP-addressable devices on your network. If the device has a responding SNMP agent that supports MIB-II, then NNM will query the agent to find more information about the device. One of the pieces of information is the SNMP system object ID (sysObjectID) of the device. The discovery service then looks at the mappings defined in the HPoid2type and oid_to_type files. These ASCII files are used to set the value of the vendor and SNMP agent fields for the object.

The vendor and SNMP agent fields for an object can be viewed from the main menu bar by selecting a symbol and Edit:Object Properties. Double-clicking on General Attributes in the Object Attributes list displays the SNMPAgent and vendor fields.

The vendor and SNMP agent field values are enumerated types that are defined in the following files:

install_dir\fields\C\ovw_fields

install_dir\fields\C\snmp_fields

As an example, the procedures of changing an object's Vendor and SNMP Agent field are listed below:

1. Make changes to oid_to_type file, for example, add in the following entry:

   1.3.6.1.4.1.94.1.1:CET Technologies:Gateway:B
   

2. Modify the ovw_fields file
   
   

   Field "vendor" {
    Type Enumeration;
    Flags capability, general, locate;
    Enumeration "Unset",
     "Hewlett-Packard",
     "HP/Apollo",
     "Acc",
       .
       .
       .
     "CET Technologies"
       .
       .
       .
   }

3. Modify the snmp_fields file
   
   

   Field "SNMPAgent" {
    Type Enumeration;
    Flags capability, general, locate;
    Enumeration "Unset",
     "HP 3000/XL",
     "HP 386",
       .
       .
       .
     "Gateway",
       .
       .
       .
     "4BSD ISODE"
   

4. Re-initialise the fields:

   ovw -fields
   

5. Force the netmon service to re-read the oid_to_type file

   xnmpolling -event
   

Adding a menu item for NNM application

Create an application registration file, eg. install_dir\registration\C\MFCSamp.rg

Application "OVw Sample" {
   Description {
       "HP OpenView Sample Application"
   }
   Version "NNM Release B.06.31  Jun 2002";

   Copyright {
 "Copyright (c) 1990-1998 Hewlett-Packard Company",
 "All rights reserved."
   }

   Command -Shared "\"C:/Program Files/HP OpenView/NNM/prg_samples/ovw_examples/MFCSample.exe\"";
   MenuBar "Misc" _i {
  "Gateway" _G f.action "gateway";
   }

   Action "gateway" {
        SelectionRule (isGateway);
   }
}

The isGateway field is defined in install_dir\fields\C\Gateway

Field "isGateway" {
 Type Boolean;
 Flags Capability;
}

Creating a NNM application

A project will be created using Microsoft Visual C++ 6.0. Standard AppWizard template is used to create a NNM application. This application then has OpenView API calls added to demonstrate calling the OVw APIs. Let's name the project MFCSamp.

The following changes were made from a standard AppWizard template:

a. Standard OpenView header files were added to stdafx.h

b. ovw.lib and ov.lib were added to the linker

c. CMFCSampApp::InitInstance was modified to initialize OpenView

d. CMFCSampApp::ExitInstance was added to terminate OpenView connection

e. Callback routines were added to MFCSamp.cpp

f. A new CMFCSampApp::OnChangeStatus was implemented to make ovw calls

g. A new module ChgStatus was added to implement the change status dialog

h. CMFCSampApp::m_pMap was added to hold the current map

i. CMFCSampApp was modified for runtime type checking (DECLARE_DYNAMIC)

j. CMainFrame::ActivateFrame was overridden to hide the main window

k. An application registration file MFCSamp.rg was written

Details:

1) add Openview initialization in:

CMFCSampApp::InitInstance()

• OVwInit()
• OVwGetMapInfo()
• OVwAddCallback(ovwEndSession, NULL, (OVwCallbackProc)endSession, this)
• OVwAddActionCallback("gateway", (OVwActionCallbackProc)changeStatusCB, this)

2) add callback functions

extern "C"
void endSession(void* userData, unsigned long eventId, int normal)
{
    CMFCSampApp* app = (CMFCSampApp*)userData;

    CWnd* wnd;
    if (wnd = app->GetMainWnd())
        wnd->PostMessage(WM_CLOSE); // Shut down application
}

extern "C"
void changeStatusCB(void* userData, char* actionid, char* menuitemid,
     OVwObjectIdList *selections, int com_argc, char** com_argv)
{
    CMFCSampApp* app = (CMFCSampApp*)userData;

    app->OnChangeStatus();
}

3) add CMFCSampApp::OnChangeStatus()

void CMFCSampApp::OnChangeStatus()
{
    CChgStatus dlgChgStatus;

    int nRet = dlgChgStatus.DoModal();

    if (nRet == IDCLOSE) {
        CWnd* wnd;
        if (wnd = GetMainWnd())
        wnd->PostMessage(WM_CLOSE); // Shut down application
    }

    if (nRet != IDOK)
        return;

    /*IDOK processing here*/
}

For Windows, OVw events are processed automatically. There is no special event processing to receive OVw events. OVwMainLoop() is provided for console applications.

4) disconnect from OVw

int CMFCSampApp::ExitInstance()
{
    OVwDone();

    return CWinApp::ExitInstance();
}

That's it.

4. References

• Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990.
• Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
• Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, May 1990.
• McCloghrie, K. and Rose, M., "Management Information Base for Network Management of TCP/IP-Based internets: MIB-II", RFC1213, March 1991.
• Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1907, January 1996.
• Hewlett-Packard Company, "Managing Your Network with HP OpenView Network Node Manager", May 2002.
• Hewlett-Packard Company, "HP OpenView Windows Developer's Guide", May 2002.
• Hewlett-Packard Company, "SNMP Developer's Guide", May 2002.
• David Perkins, Evan McGinnis, "Understanding SNMP MIBs", 1997.

---

©Victor Yeo

® First Created: Wed June 4 2003

Last Updated: Wed August 22 2003