HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Management

To display configuration information in the SNMP configuration database, use the SHOW CONFIGURATION SNMP command. If you want to display the addresses that the agent recognizes as members of the community, use the /FULL qualifier. For example:

TCPIP> SHOW CONFIGURATION SNMP /FULL

SNMP Configuration

Flags:    AuthenTraps  Sets

Contact:  Sam Spade

Location
  First:  Falcon Building
  Second: Los Angeles, CA

Community           Type       address_list

public              Read       0.0.0.0

writeit             Read Write 9.20.208.53

trapit              Read Trap  9.20.208.53, 9.20.208.100

In this example, the configuration allows read access to any client on any host through the public community and read/write access to the client on host 9.20.208.53 through the writeit community. In addition, trap messages are sent to UDP port 162 on hosts 9.20.208.53 and 9.20.208.100.

Alternatively, you can display the configuration options in the SNMP configuration text file described in Section 14.4.3. For more information, see Section 14.6.5.2.

14.4.3 SNMP Options

You can configure the way SNMP runs by entering SNMP options into the SNMP configuration file TCPIP$VMS_SNMP_CONF.DAT.

When it starts, the SNMP master agent creates the temporary file SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$TMP_SNMP_CONF.DAT from data in the standard TCP/IP configuration database file TCPIP$CONFIGURATION.DAT. For troubleshooting purposes, a few versions of this file are preserved. The master agent appends this temporary file to TCPIP$VMS_SNMP_CONF.DAT to produce the master configuration file TCPIP$SNMP_CONF.DAT.

When the standard OS_MIBS and HR_MIB subagents start up, they read TCPIP$SNMP_CONF.DAT. Only the master agent and these standard subagents use values in the text files.

By default, custom subagents do not take advantage of the configuration options. To take advantage of these options, you must assign a logical that is visible to the subagent process. The following example shows how to define TCPIP$SNMP_GEN_LOGFILE logical to set the snmp_gen_logfile configuration option:

$ ASSIGN/SYSTEM 1 TCPIP$SNMP_GEN_LOGFILE

If a configuration option is not handled by the eSNMP API, the subagent must include an explicit genenv() or similar call to access the value of the option.

14.4.3.1 Using Logical Names to Configure SNMP

Most configuration options have a corresponding logical name. In some cases, you can define system logical names as an alternative to entering a value in the text file. For a list of the options and their associated logical names, see Section 14.4.3.4.

14.4.3.2 Dynamic Options

Some options are available for you to change dynamically; that is, without shutting down and restarting the SNMP service. To change configuration values dynamically, you can do one of the following:

• Define the appropriate logical name.
• Edit the configuration file, then define snmp_signal to be sighup . Be sure to deassign snmp_signal afterwards to prevent continuous rereading of the configuration file.

The master agent and the subagents convert lines in the configuration file that begin with the OpenVMS-specific config command to user-mode process logicals by adding the prefix TCPIP$. For example, SNMP_GEN_LOGFILE becomes TCPIP$SNMP_GEN_LOGFILE. (This mechanism does not apply to options with other keywords, such as trap .) Because the logicals are local to agent processes, they are not visible to a DCL command SHOW LOGICAL issued in another process.

If there are lines with duplicate configuration tags, the last line supersedes all others. Because the temporary file TCPIP$TMP_CONF.DAT (described in Section 14.4.3) is appended after the user-editable TCPIP$VMS_SNMP_CONF.DAT file, the standard TCPIP configuration values from that temporary file always supersede those from the user-edited file.

Lines in the configuration file that begin with a pound sign (#) are ignored. The pound sign is the comment character.

Option names and values are not case sensitive. Boolean values are considered on if the option is present with no value. Otherwise, they are considered off. Thus, to turn off an option that was enabled at startup, you must specify zero as the value.

If you specify a value that is longer than the limit, the value is converted to hexadecimal and then truncated. For example, if you specify the value 257 in place of an 8-bit unsigned value, it is converted to hexadecimal (0101) and truncated to 1.

14.4.3.4 SNMP Configuration Options

Most of the SNMP options set in the TCPIP$VMS_SNMP_CONF.DAT file must be entered using the following syntax:

config option-name value

There are several types of SNMP configuration options:

• Logging options, described in Table 14-3. These options control the way messages are logged.
• Operation options, described in Table 14-4. These options control the operational settings for SNMP. Some of these options cannot be set by using a logical name.
• Timing options, described in Table 14-5. These options control the way timeouts are handled.
• Testing and troubleshooting options, described in Table 14-6. These options are useful when you are testing SNMP functions and troubleshooting subagent problems.
• Backward-compatibility options, described in Table 14-7. These options are available to provide compatibility with subagents developed under previous versions of SNMP.

Except for the community name, option values are not case sensitive.

Time-related parameters are important in determining the responsiveness of the SNMP agents to client requests, particularly on systems with limited memory or those that are heavily loaded.

On startup, each subagent first sets up a default session timeout (see the AGENTX_SESSION_TIMEOUT option). It then registers its MIB regions. The subagent can register each of its MIB regions with a different timeout. A value of 0 causes the session timeout for the entire subagent to be used.

The master agent listens for SNMP requests. The timeout value is 10 seconds, unless the SNMP_MASTER_TIMEOUT option has been defined. After a timeout occurs, the master agent updates counters, checks for requests, then loops to wait for another SNMP request. When an SNMP request arrives, the master agent determines which if any registered subagents can handle it. It then resets the SNMP_MASTER_TIMEOUT timeout to use the maximum of the timeouts for all MIB regions involved.

When it is not processing an SNMP request, a subagent may send are_you_there messages to the master agent at a default interval determined by the subagent. For the chess example, the default is 30 seconds; for the OS_MIBS and HR_MIB subagents, the default is 5400 seconds (90 minutes). Both values are derived from those used in the UNIX implementation of SNMP; the second value was set high to minimize system overhead.

The following relationships among configuration option values are recommended but are not enforced. See the descriptions of the specific options for details.

• SNMP_ARE_YOU_THERE_TIME and SNMP_INACT_TIME
  The SNMP_ARE_YOU_THERE_TIME option determines the time between are_you_there messages. If the SNMP_INACT_TERM option is set, and if the master agent does not receive any SNMP request or are_you_there mesages from a subagent during the time associated with the SNMP_INACT_TIME option, the master agent automatically exits. By default, the SNMP_INACT_TERM option is not set.
  If the SNMP_ARE_YOU_THERE_TIME option is not set and no external SNMP requests are received, the master agent will exit even if subagents are still active.
• SNMP_INACT_TIME and SNMP_POLL_TIME
  The values for these options should be a multiple of the value of the SNMP_MASTER_TIMEOUT option.
  The master agent checks whether these intervals have elapsed after the time specified by the SNMP_MASTER_TIMEOUT option. Therefore, a value for these two options that is not a multiple of SNMP_MASTER_TIMEOUT will have the same effect as one that is the next higher multiple.
• The client should allow a large enough timeout interval to accommodate the server to avoid query failures or unnecessary retries. Particular care is required when network load is high and when communicating with heavily used servers and those in which tracing is turned on. See Table 14-6 for details on using trace.