SunNet Manager SNMP Proxy Agents

Solstice Enterprise Manager 4.1 Customizing Guide

Chapter 10

SunNet Manager SNMP Proxy Agents

This chapter describes the configuration and operation of the SunNet Manager SNMP proxy agents. For information on installing the SNM agents and proxies, refer to the Chapter 6 of Installation Guide.

Note – For purposes of this guide, SunNet Manager (SNM) refers to the 2.2 or later releases of SunNet Manager, and releases of Solstice Site Manager and Solstice Domain Manager. SunSoft makes no claims of compatibility of Solstice Enterprise Manager (Solstice EM) with versions of SNM prior to 2.2.

This chapter describes the following topics:

Section 10.1 Proxy Agents
Section 10.2 SNMP Proxy Agent Operation
Section 10.3 SNMP Trap Daemon (em_snmp-trap) Operation
Section 10.4 Schema Files
Section 10.5 SNMP Version 2 Support

10.1 Proxy Agents

The SunNet Manager (SNM) agents provided with Solstice EM include proxy agents to support Simple Network Management Protocol (SNMP) and SNMP Version 2. Proxy agents allow for distribution of polling of SNMP devices to multiple locations in the network.

SunNet Manager requests can be launched from the Solstice EM MIS using the request-handling capabilities of the Solstice EM Nerve Center (as described in Chapter 17). Polling of the managed resource at the specified intervals is handled by the SNM proxy agent rather than the Nerve Center, minimizing network traffic and the polling work required of the MIS.

Proxy agents run on one of the following platforms:

Sun workstations running SunOS 4.x
Sun workstations running Solaris 2.x
PCs running Solaris 2.x/x86.

The Solstice EM MIS communicates with the SNMP proxy agents using the same Remote Procedure Call (RPC) protocol as other SNM agents. The SNMP Version 1 proxy agent (na.snmp) communicates with other network devices using the SNMP protocol defined in RFC 1157. The SNMP Version 2 proxy agent (na.snmpv2) is discussed below in Section 10.5 SNMP Version 2 Support.

The SNMP proxy agent allows you to manage any number of management information bases (MIBs) in which you can define either standard SNMP MIB objects or enterprise-specific objects. The proxy agent uses a SunNet Manager schema file to map objects described in a MIB and in SunNet Manager attributes. A schema file is the representation of a MIB used by SunNet Manager.

Communication between the Solstice EM MIS and SNMP devices, using the RPC-based SNMP proxy agents, thus requires three representations of the MIB structure:

The SNMP MIB on the agent system containing the managed resource
The SNM schema mapping of the MIB, which resides on the proxy system
The GDMO and ASN.1 documents, defining the managed object class, which is loaded into the MIS

FIGURE 10-1 MIB, GDMO, and Schema Definitions
Generating GDMO object classes from SNMP MIBs is described in Chapter 8 of Management Information Server (MIS) Guide. How to generate SNM schema files from MIBs is discussed later in this chapter. To ensure successful operation, there must be an identical mapping of object definitions between the SNMP MIBs, the GDMO documents and the SNM schema files, as shown in the above figure.

The following SunNet Manager SNMP schemas are supplied with Solstice EM:

snmp.schema describes MIB I, as defined by RFC 1156.
snmp-mibII.schema describes MIB II, as defined by RFC 1213.
snmpv2-mibII.schema describes MIB II, as used by SNMP version 2. See the "SNMP Version 2 Support" section for a description of SNMPv2 support. This schema is used only by the na.snmpv2 agent.
sun-snmp.schema describes the MIB associated with the SNMP agent (snmpd) for Sun workstations. This schema file provides MIB II support with Sun enterprise-specific extensions. For more information about the
sun-snmp.schema, refer to the Site/SunNet/Domain Manager Reference Manual.

Except for the two MIB II files (which differ only in the RPC number specified), each of the schema files listed above is a subset of the file that follows it. That is, snmp.schema is a subset of the two MIB II files, which, in turn, are a subset of sun-snmp.schema.

The SNMP proxy agent can simultaneously access any of the above-mentioned schemas, as well as other enterprise-specific schemas that you might create. The SNMP proxy agent uses the keyword na.snmp.schemas in the snm.conf file to locate the directories where the SNMP schema files reside.

The following section describes in detail how the SNMP proxy agent works. Note that many of the operations of the proxy agent are defined by arguments passed in the SNM request or with keywords in the snm.conf file on the proxy system. Refer to the snm.conf entry in the Site/SunNet/Domain Manager Reference Manual for information on the keywords that are related to the SNMP proxy agent.

10.2 SNMP Proxy Agent Operation

The default operation of the SNMP proxy agent is configured by values specified in the snm.conf file. These parameters are identified by various keywords. The affect of these settings is described below. The SNMP proxy agent operation is illustrated in the following figure.

FIGURE 10-2 SNMP Proxy Agent Operation
When the SNMP proxy agent starts up (normally via inetd) it loads all the SNMP schemas located in the directories specified by the keyword na.snmp.schemas in the snm.conf file on its host system. Only SNMP-related schemas (schemas that contain an rpcid keyword value of `100122') are loaded.

When the SunNet Manager SNMP proxy agent receives a request for an SNMP agent on a particular device, it performs the following sequence of operations:

It checks whether there are any new or modified SNMP related schema files since the last request. If the proxy agent finds a new or modified schema in any of the directories specified by the na.snmp.schemas keyword in the snm.conf file on the proxy's system, it loads the schema file.
It passes the request to an existing agent subprocess or forks a new subprocess, if needed, to handle the request. A single subprocess can handle multiple SNMP requests from an instance of a management application. The maximum number of subprocesses that the SNMP proxy agent can fork is set by the keyword na.snmp.max-subprocs in the snm.conf file. At installation, this value is set to 20. The maximum number of requests that a subprocess can handle is set by the keyword na.snmp.max-requests in the snm.conf file. At installation, this value is set to 50.
It checks whether the request contained any optional arguments. Requests sent by the Solstice EM Nerve Center may include arguments in an SNMP request. These arguments can include:

The name of the schema to be used with the request. If, for some reason, the specified schema does not contain the attribute group specified in the request, the proxy agent attempts to use the schema specified by the keyword na.snmp.default-schema in the snm.conf file on its host system. At installation, the default schema is set to be:
/usr/snm/agents/snmp-mibII.schema for Solaris 1.x installations
/opt/SUNWconn/snm/agent/snmp-mibII.schema for Solaris 2.x installations

This schema supports the MIB II definition.

A community name that specifies the SNMP community name the proxy agent is to use when reading or writing attribute values. If no community name is specified, public is used for both Get and Set requests.
A request timeout that specifies the number of seconds the proxy agent is to wait for a response to a request sent to the target system. If no request timeout is specified, the proxy agent uses the value specified by the keyword na.snmp.request_timeout in the snm.conf file on its system. At installation, the value is set to 5 (seconds).

The proxy agent then sends an SNMP message to the device and waits for a response.

If the proxy agent is sending a Get request, the proxy sends up to three SNMP requests per reporting interval. (The maximum number of SNMP requests sent is specified by the keyword na.snmp.max_attempts in the snm.conf file, by default the value is set to 3.) For each SNMP PDU sent, the proxy waits for the specified request timeout for a response from the device. As mentioned previously, the request timeout can be an optional argument in the request. If it is not specified in the request, request timeout is either the request timeout value specified in the SNMP host file for the device or the value of the keyword na.snmp.request_timeout in the snm.conf file.
If the proxy agent does not receive a response after sending three SNMP requests, it sends a "No response from system" report to the Event Dispatcher (na.event) (The keyword na.snmp.trap-if-no-response in the snm.conf on the proxy system determines whether the proxy agent sends a trap or an error report. At installation, the keyword's value is true--send a trap report.) The proxy agent then waits until the next reporting interval to send out another set of SNMP requests. If no reporting interval has been specified in the request, the proxy agent sends out SNMP requests every 30 seconds. If the proxy agent does not receive a response when the last report is due, it sends both an error report and a trap report to na.event if na.snmp.trap-if-no-response is true.
If the proxy agent is sending a Set request, the proxy waits for the specified request timeout for a response before timing out. There is no attempt to re-send the request. The reason for this is as follows: Because UDP is the transport mechanism, there is no guarantee of message delivery, thus there is no way to determine whether the request or the response to the request was lost. If you do not receive a response from your initial Set request, you should perform a Get request to see whether or not the Set operation was successful.

When the proxy agent receives a response from the target device, it sends a report to the Event Dispatcher (na.event) on the management machine that initiated the request.

If the proxy agent does not receive an acknowledgment from the event dispatcher within a specified time, the proxy agent terminates the request. The specified time that the proxy waits for the event dispatcher to acknowledge the report is specified by the na.snmp.report_timeout keyword in the snm.conf file. At installation, the keyword's value is set to 5 (seconds).
Normally, if the SNMP proxy agent is not performing any requests, it will exit. The keyword na.snmp.exit-if-no-requests in the snm.conf file allows you to specify otherwise.

10.3 SNMP Trap Daemon (em_snmp-trap) Operation

Asynchronous or unexpected event notifications (traps) from SNMP agents are handled by the SNMP trap daemon (em_snmp-trap), which may run on one or more machines on the network. The daemon listens for incoming traps on the SNMP trap port (port 162). The trap daemon does the following with incoming traps:

SNMP traps are converted to CMIP event notifications, as specified by the trap daemon's trap_maps configuration file, and sent to the MIS.
SNMP traps are also translated into SunNet Manager traps for use by SNM applications. SNM applications that register with the event dispatcher receive the incoming SNM traps forwarded by the trap daemon. The trap daemon uses a SunNet Manager SNMP trap file, which contains information on enterprise-specific traps.
You may also specify forwarding of raw SNMP traps to other managers.

Configuration of the Solstice EM SNMP trap daemon is described in Chapter 11.

10.4 Schema Files

If you do not already have an SNM schema file for the device you want to manage via the RPC-based SNMP proxy agent (na.snmp), use the mib2schema utility to convert an existing MIB file for the device. The mib2schema utility supports conversion of MIBs adhering to the following Internet standards:

RFC 1156--MIB-I
RFC 1213--MIB-II
RFC 1155--SMI
RFC 1212--Concise MIB definition
RFC 1215--Defining traps

To create a schema file for managing devices via the SNMP Version 2 proxy agent (na.snmpv2), use the v2mib2schema utility to convert the MIB to a V2-compatible schema. The v2mib2schema utility is described below in Section 10.5.3 Using the v2mib2schema Program.

Note – Nested groups or tables are not supported in SNM schema files.

You may need to manually edit the resulting schema file produced by mib2schema. The areas that are likely to require changes are as follows:

When mib2schema encounters an OCTET STRING, it inserts -C ??? in place of a format string. If you want to format octet strings in a particular way, search the schema file for occurrences of -C ??? to replace ??? with the required format string. If a format string is specified, the SNMP proxy agent formats each octet of the attribute value it receives from an SNMP agent before sending the attribute value to a SunNet Manager rendezvous. You may, however, choose not to enter any format string. In this case, the contents of the OCTET STRING will be printed as is.

The format string is the same as the sprintf(3S) format argument. Up to 16 octets can be formatted; each byte is sent to sprintf as a separate, unsigned character. For example, the format string:

%02.2X:%02.2X:%02.2X:%02.2X:%02.2X:%02.2X

causes an OCTET STRING containing a 48-bit Ethernet address to be formatted in standard colon notation (for example, 08:00:20:07:8F:93).
Note – The format string and the length of the OCTET STRING to be formatted must match. All bytes specified in the format string are displayed. If the OCTET STRING is smaller than the format string, unexpected characters may be displayed in the formatted output.

Note that the -C format parameter is only used if the parameter -T STRING is specified for the attribute. If the parameter -T STRING is specified and
-C format is not specified, the attribute is displayed as either octets or as a string, depending upon whether the attribute is an octet or display string.
An example of the characteristics string for the ifPhysAddress attribute in the ifStatus table is shown below:

"-N ifPhysAddress -O 1.3.6.1.2.1.2.2.1.6 -T STRING -A RO
-C %2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X -X equal -F 0"

This results in the display:

ifPhysAddress=08:00:20:09:A0:D5

Some SNMP devices cannot return groups or tables with a large number of attributes; this is due to local space limitations. When this happens, the SNMP proxy agent returns an error message that the response is "too big". This means that very large groups or tables need to be split into smaller groups or tables to be received by the SNMP proxy. mib2schema does not automatically split groups or tables. Generally, if a group has more than 15 fields, it is a good idea to split the fields up into smaller groups. You can choose your own name for subgroups.

In addition to the schema file, the mib2schema utility produces an object identifier file (with the .oid suffix) that contains a table of object identifiers and names. The object identifier file is required only if you want SNMP traps forwarded as SNM traps to SunNet Manager Consoles. For SNM Console support, the contents of the .oid file need to be added to the SNM Object Identifier Database, using the SNM build_oid utility. For more information, refer to the build_oid entry in the Site/SunNet/Domain Manager Reference Manual.

mib2schema may also produce a trap definition file (with the.traps suffix), depending upon whether traps were specified in the MIB. This file is used for mapping enterprise-specific traps into SunNet Manager trap format for use by the SNM Console. Refer to the Solstice Site/SunNet/Domain Manager Administration Guide for more information.

If mib2schema cannot determine the key for a table characteristics field in the schema file, it inserts -K ??? into the schema file.

10.5 SNMP Version 2 Support

Solstice EM provides support for SNMP Version 2 through the SunNet Manager SNMP Version 2 proxy agent (na.snmpv2). This section assumes you are familiar with SNMPv2 concepts.

SunNet Manager provides a proxy agent that supports SNMPv2. This proxy agent allow you to get data and event information from and set attribute values for devices managed through SNMPv2.

There is also an SNMP agent for Sun workstations called the snmpv2d daemon. The MIS communicates with this daemon through the SNMP proxy agent. The snmpv2d daemon also allows Sun workstations to be managed by other SNMPv2 and SNMP stations. For more information about the snmpv2d daemon, see the snmpv2d entry in the Site/SunNet/Domain Manager Reference Manual.

The following sections discuss the differences between SNMP and SNMPv2. For information about the SNMPv2 configuration files, see the following man pages:

v2install(1), acl.pty(5), agt.pty(5), context.pty(5), mgr.cnf(5), mgr.pty(5), snmpv2d.conf(5), and view.pty(5).

These man page entries are also provided in hardcopy and AnswerBook form in the Solstice Site/SunNet/Domain Manager Reference Manual.

Note – When the Discover tool locates SNMP devices on your network, it cannot determine whether the devices support functionality specific to SNMPv2.

10.5.1 SNMPv2 Enhancements

The key enhancements from SNMP to SNMPv2 are in the following categories:

Structure of Management Information (SMI)
Protocol operations
Manager-to-manager capability
Security

10.5.1.1 Structure of Management Information

The SMI for SNMPv2 is based on the SMI for SNMP. The SNMPv2s SMI provides more extensive specification and documentation of managed objects and MIBs.

Several new data types were created for SNMPv2. These include a 64 bit-counter (Counter 64) and the UInteger32 type which allows representation of integers in the range 0 to 2³² - 1.

The SNMPv2 OBJECT-TYPE macro includes an optional UNITS clause, which contains a textual definition of the units associated with an object. This clause is useful for any object that represents a measurement in units (ex. "seconds"). The OBJECT-TYPE macro for SNMPv2 also incudes a MAX-ACCESS clause which allows you to specify the maximum level of access.

10.5.1.2 Protocol Operations

SNMPv2 has three new protocol data units (PDU). The SNMPv2 trap PDU works in a way similar to that of the SNMPv1 trap PDU, but it uses a different format from the SNMPv1 trap PDU. Its format is changed to be the same as most other SNMPv2 PDUs. This eases the receiver processing task.

A major enhancement for SNMPv2 is the GetBulkRequest PDU. This PDU can significantly minimize the number of protocol exchanges required to retrieve a large amount of management information. This PDU is presently not used by Solstice EM for its operation.

The third additional PDU is the InformRequest PDU. This is sent by an SNMPv2 manager, on behalf of an application, to another SNMPv2 manager. The Protocol Data Unit (PDU) provides management information to an application using the second SNMPv2 manager.

10.5.2 SNMPv2 Files

You can install SNMPv2 as an agent (snmpv2d), a manager (na.snmpv2), or both. The required files are installed as part of the current product. Installation steps are the same for both agents and managers. Before running the v2install script, you will need to create the three configuration files required by the v2install script. The files are as follows:

agents--contains names of hosts on which the snmpv2d agent will be installed
mgrs.v1--contains names of hosts that will be running SNMPv1 managers (na.snmp)
mgrs.v2--contains names of hosts that will be running SNMPv2 managers (na.snmpv2)

See the v2install(1) man page, or the v2install entry in the Site/SunNet/Domain Manager Reference Manual, for detailed information about these files.

10.5.3 Using the v2mib2schema Program

A program, v2mib2schema, has been included with the current product to allow you to translate your own SNMPv2 MIBs to SNM schema files.

Be aware that SunNet Manager schemas do not have the flexibility of SNMPv2 MIBs, so changes to the MIB may be necessary before v2mib2schema can successfully parse it.

Although v2mib2schema parses TEXTUAL-CONVENTIONS clauses, it currently ignores them, so later references to the new types will cause syntax errors. See the v2mib2schema(5) man page (or v2mib2schema entry in the Site/SunNet/Domain Manager Reference Manual) for more details.

%02.2X:%02.2X:%02.2X:%02.2X:%02.2X:%02.2X

"-N ifPhysAddress -O 1.3.6.1.2.1.2.2.1.6 -T STRING -A RO -C %2.2X:%2.2X:%2.2X:%2.2X:%2.2X:%2.2X -X equal -F 0"

Doc Set | Contents | Previous | Next | Index