HP TCP/IP Services for OpenVMS

Previous Contents Index

14.5 SNMP Log Files

Unless the SNMP_TRACE option is set, output from the SNMP master agent and subagent processes to SYS$OUTPUT is redirected to the following files:

The output is written to these files continuously while SNMP processes are running. Buffering may cause a delay in writing to disk; therefore, if a process is terminated abnormally, some data may be lost.

While processes are running, output for SYS$ERROR can be redirected to other files. See Section 14.4.3 for information about controlling this. In addition, the master agent and subagents may write to SYS$ERROR. This output is redirected to the following files:

Unlike a regular log or a trace log, this output is written when the corresponding SNMP process terminates. Therefore, abnormal termination can cause data to be lost.

All of the listed log files are located in the SYS$SYSDEVICE:[TCPIP$SNMP] directory. The configuration-related files described in Section 14.4.3 are also stored there. TCP/IP Services does not allow you write to log files in other directories.

The log level and specific events during processing determine how much information is recorded in the log files; log files can be empty or nonexistent.

The log files contain startup and event information and additional messages, depending on the logging level specified for an agent. The SNMP logging facility uses three logging levels:

The default logging level for the master agent and standard subagents is Warning. Because the Chess example subagent does not use a default, messages are captured only if you specify tracing, as described in Section 14.6.4.

Many logging options are configurable using the text configuration file SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT; see Table 14-3 for more details.

The following log files exist under normal production conditions if special configuration options are not used. In most cases, a new version of each file is created each time SNMP is started:

1If no output has been generated, a .LOG or .ERR file might not exist.

If the configuration option SNMP_GEN_LOGFILE is set, files in the preceding table continue to be used for SYS$ERROR data. For SYS$OUTPUT data, as soon as the agents detect the option, data is written to the following files, where process-ID is the hexadecimal process ID of the process listed:
Agent Process SYS$OUTPUT

Unless it is suppressed, the timestamp gives a line-by-line record of when output was written to each file and is useful in resolving timing-related problems.

The SNMP_GEN_LOGFILE option does not affect the name of the output file for customer written subagents. Customer-written subagents generate files based on the IMAGENAME symbol in SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM.

For details about logging from customer extension subagents, refer to the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

14.6 Solving SNMP Problems

The following sections contain information about how to analyze and solve many SNMP problems. Be sure to configure SNMP according to the instructions in this guide, and use the information here and in the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide when writing your own subagents.

14.6.1 Multiple SNMP Processes Displayed for SHOW SYSTEM Command

When you enter the DCL command SHOW SYSTEM during the TCPIP or SNMP startup sequence, the process TCPIP$SNMP_n may appear in the display without the subagent processes (TCPIP$OS_MIBS and TCPIP$HR_MIB). This is because TCPIP$SNMP is the main SNMP process started by the TCP/IP kernel when the SNMP service is enabled; it starts the subagents as detached processes, and then continues to run as the master agent. The number at the end of this process name reflects the number of times this main process has started since SNMP has been enabled.

14.6.2 Problems Starting and Stopping SNMP Processes

If there are startup errors noted in the SNMP log files, or if SNMP startup seems normal but one or more of the SNMP processes disappears, follow these steps:

  1. Check the log files for any errors indicating timeouts, protection problems, or configuration errors.
  2. Start up the master agent and subagents by running the images interactively and enabling tracing (see Section 14.6.4).

To verify the SNMP installation, enter the command SHOW CONFIGURATION SNMP, as described in Section 14.4.2.

To stop all SNMP processes, enter:


If you disable the SNMP service by entering the DISABLE SERVICE SNMP command, automatic restarts are prevented, but detached SNMP master and subagent processes are not stopped.

14.6.3 Restarting MIB Subagent Processes

Usually the SNMP master agent and subagent processes start up and are shut down together as described in Section 14.1.1.

If the SNMP master agent process stops for any reason, TCP/IP Services attempts to restart it and, if successful, increments the count (n) in the process name TCPIP$SNMP_n. As part of the startup sequence, any subagents that have stopped will be restarted. If a subagent process has not stopped, an attempt to restart it will have no effect because OpenVMS does not allow a duplicate process name (unlike the SNMP master agent, subagent names do not include a startup count).

If the master agent continues to run but a subagent stops, there is no automatic restart attempt. You can correct the problem by doing one of the following:

14.6.4 Obtaining Trace Log Messages

To get trace log messages you can:

To configure SNMP to log tracing messages while it is running, set the snmp_trace configuration option. With this option enabled, trace output is produced and written to standard logs (see Section 14.5) when agents are run in normal production mode.

See Section 14.4.3 for details about the configuration options and about how to enable those options dynamically or without running interactively.

To obtain trace log messages interactively, follow these steps:

  1. Shut down SNMP. Enter:


  2. From separate windows, run the master agent and subagents interactively. For example, run each image by entering the following commands in separate windows:


    To specify custom subagents located in directories other than SYS$SYSTEM, use the MCR command and specify the full directory path. For example, to run the Chess example subagent with trace logging, enter the following command:


When agents are run interactively, output comes to the terminal unless the SNMP_GEN_LOGFILE option is enabled.

Running in trace mode can produce a great deal of output, and also slow down performance significantly. Programs like browsers may need to allow a longer timeout interval under these circumstance. For example, use the -w with the supplied MIB browser.

For more information about the MIB browser supplied with TCP/IP Services, and on using tracing with custom subagents, see the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

The type of trace data written depends on the way the subagent routines are programmed, except for logging handled within eSNMP API routines. For more details, see the Chess example code.

14.6.5 Processing Set Requests and Traps

To make sure that the master agent processes SNMP Set requests from management clients correctly, follow these steps:

  1. Configure SNMP to allow the master agent to process Set requests, either by using the TCPIP$CONFIG.COM configuration procedure or by using the SET CONFIGURATION SNMP command.
  2. Make sure that the management client is configured correctly for Get and Set requests, as described in the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.
  3. Configure write communities as needed on the OpenVMS server. Refer to Section for more information.
  4. Make sure that the requested MIB variable is defined with write access and implemented as such in the subagent. Refer to the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide for more information.

If SNMP is not responding to Set requests after you follow these steps, refer to Section 14.6.6 for troubleshooting procedures and Section to check the community configuration information. Enabling Set Request Processing and Authentication Traps

On an OpenVMS server, configure SNMP with the /FLAGS=SETS qualifier to the management command SET CONFIGURATION SNMP, or enable SNMP during the configuration procedure (TCPIP$CONFIG) by answering Yes to the question Do you want to allow clients modify (SET) access?

To enable set requests and traps on an existing SNMP configuration, enter the SET CONFIGURATION SNMP command with the /FLAGS=options qualifier, specifying the SETS option to enable set requests and the AUTHEN_TRAPS option to enable sending authentication failure traps.

When you enter the SET CONFIGURATION SNMP command and qualifiers, take the following information into consideration:

For example, to enable response to set requests and to allow authentication traps on an existing SNMP configuration, enter the following command:


See the HP TCP/IP Services for OpenVMS Management Command Reference guide for detailed information about the SET CONFIGURATION SNMP command.

Restart SNMP after making any changes to the configuration. Displaying Configuration Information

When you enter the SHOW CONFIGURATION SNMP command to display your current SNMP configuration, the information associated with the /FLAGS=options qualifier is displayed as follows:

Flags:    AuthenTraps Sets 

SNMP will function even if you do not include the /FLAGS=SETS and /FLAGS=AUTHEN_TRAPS qualifiers.

To remove flags that were set previously, enter the following commands:


Alternatively, you can display configuration information in the SNMP configuration file (SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT). The configuration file displays more information than the SHOW CONFIGURATION SNMP command when multiple types of traps or addresses for them have been defined. For example:

trap      V1 elmginkgo 
community     alternate read 
community         public read 
community         TRAPIT write 
trap      v2c     TRAPIT 
community         rw       write 
community         rw     write 

Note that the first two lines of the configuration file are not displayed by the following SHOW CONFIGURATION SNMP/FULL command:

Community           Type           Address_list 
public              Read  
TRAPIT              Read Write Trap 
rw                  Read Write, Specifying Location and Contact Information

To specify the location and contact information, include the /LOCATION and /CONTACT qualifiers on the SET CONFIGURATION SNMP command line.

If you do not specify the location and contact information, it is displayed as "not defined" by the SHOW CONFIGURATION SNMP/FULL command. For example:

SNMP Configuration 
Flags:    Sets 
Contact:  not defined 
Location: not defined 

To remove a previously specified location, enter:



If you enabled SNMP when you had a previous version of TCP/IP Services installed, you might need to specify NOTHIRD through NOSIXTH to remove existing location information.

Once you specify a contact name using /CONTACT=name, you can change the name but you cannot remove it. If you enter /CONTACT=" ", the previously specified contact name remains in effect. Verifying Community Information

To display the community strings for the OpenVMS host, enter the following command:


Also, check the community configuration in the TCPIP$VMS_SNMP_CONF.DAT file, as described in Table 14-4.

Make sure that the community string used in the messages matches a valid community of the appropriate type on the server. Check also that the MIB variable is defined with write access and implemented as such in the subagent. Note that in OpenVMS standard MIBS, the Set command is not implemented for some variables defined as writable in the MIB II and Host Resources MIB.

For example, the community must be configured as /TYPE=(READ,WRITE) to process set requests.

If SNMP is not responding to set commands or to other requests: Enabling SNMP Version 1 Traps

By default, SNMP sends Version 2 traps, which can be configured using either the TCPIP$CONFIG.COM procedure or the SET CONFIGURATION SNMP command. You can modify SNMP to send Version 1 traps by default, using the trap option described in Table 14-4.

You can implement individual SNMP Version 1 traps even if Version 2 traps are set by default. Add a line for each trap destination to the TCPIP$VMS_SNMP_CONF.DAT file using the following format of the trap option:

trap v1 community IP-address[:port] 

When SNMP Version 1 traps are set by default, you can send SNMP Version 2 traps by adding a line to the TCPIP$VMS_SNMP_CONF.DAT file for each Version 2 trap destination using the following format of the trap option:

trap v2c community IP-address[:port] 

In these formats:

Regardless of the default trap type, you can control the trap type for each trap destination using the appropriate tag ( v1 or v2c ). For example, the following entries in the TCPIP$VMS_SNMP_CONF.DAT file will cause a Version 1 trap to go to the host with the IP address (community name v1type), and a Version 2 trap to go to the host with the IP address (community name v2type). Both traps will go to the well-known port 162:

trap v1 v1type 
trap v2c v2type 

14.6.6 Solving Management Client Response Problems

When an SNMP client is not getting a response to set , get , getnext , or getbulk requests, even though the SNMP server is configured and running, the problem might be with the operation of the subagent or in the transmission of the query or response message. To test, follow these guidelines:

  1. Confirm that TCP/IP Services is running on your host. Enter:


  2. To ensure the successful startup of the SNMP master agent and subagents and the operation of the TCPIP$SNMP_REQUEST utility (MIB browser), confirm that the BIND resolver has been configured correctly by entering the following command:


    Refer to Chapter 6 for information about configuring the BIND resolver.

  3. Check the status of the SNMP service using the following DCL command:


    This command shows when each TCP/IP Services service startup completed and which user performed each startup. If the SNMP service is not listed, it was either shut down or it was not started.

  4. Use the MIB browser on the host to retrieve the OID in question, as described in HP TCP/IP Services for OpenVMS SNMP Programming and Reference.
  5. If the local query is successful, use a MIB browser from another host. This is useful when timeout problems indicate that network delays are the cause of the problem.
  6. Check the log files for any problems associated with SNMP startup. For detailed information, start the SNMP components separately with tracing enabled, as described in Section 14.6.4.
  7. Use a protocol analyzer to intercept messages going to the target. The TCPTRACE utility is available on OpenVMS hosts. Enter the DCL command HELP TCPTRACE for information about how to use this utility. For the failing message:
  8. Check for problems with ownership, protections, or installation of images, using standard OpenVMS DCL commands, such as DIRECTORY and INSTALL.
    For example, the following message indicates that one of these factors is a possible problem:

    WARNING: select returned -1 on snmpd sockets: not owner 

    The owner for all SNMP executables should be [SYSTEM]. At a minimum, the protection should be set to S:RWED,O:RWED,G:RE,W:RE.

  9. If you cannot get a response for MIB variables handled by certain subagents, verify that the subagents are running by entering the following command:


    Check for the following processes:

    See the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide for descriptions of these processes.
    Also check for custom subagents whose process names appear after RUN commands in the following command procedure:
    If these processes and additional subagents follow the model of the Chess example, they should be in LEF state. Excessive time in HIB state indicates a problem. If the processes are not there, check log files for the possible cause of abnormal termination. Note that you must run the SYS$STARTUP:TCPIP$SNMP_SHUTDOWN.COM procedure in order to see entries in the latest .LOG and .ERR files. If a query on members of the hrFSTable group results in no response or in a "no such name" response, the problem might be one of the following:
    Additional problems occur if file protections or installation privileges were changed on SYS$SYSTEM:TCPIP$HR_MIB.EXE.

Previous Next Contents Index