HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Management

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:

• TCPIP$SNMP_RUN.LOG
• TCPIP$OS_MIBS.LOG
• TCPIP$HR_MIB.LOG

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:

• TCPIP$SNMP_RUN.LOG
• TCPIP$OS_MIBS.ERR
• TCPIP$HR_MIB.ERR

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:

• Trace (logs trace, warning, and error messages)
• Warning (logs warning and error messages)
• Error

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:

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:

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:

$ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN

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:

• Restart TCP/IP Services.
• Restart SNMP.
• Manually stop the TCPIP$SNMP_n process to force a master agent restart.
• Configure the SNMP variable AUTRESTARTS and stop all the subagent processes. See Section 14.4.3 for more information.

To get trace log messages you can:

• Configure SNMP to enable trace output while SNMP continues processing.
• Enable tracing while running SNMP interactively.

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:

   $ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN

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

   $ MCR TCPIP$ESNMP_SERVER -T $ MCR TCPIP$OS_MIBS -TRACE $ MCR TCPIP$HR_MIB -TRACE

   
   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:

   $ MCR SYS$COMMON:[SYSHLP.EXAMPLES.TCPIP.SNMP]TCPIP$CHESS_SUBAGENT -TRACE

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 14.6.5.2.2 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 14.6.5.2.2 to check the community configuration information.

14.6.5.1 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:

• SNMP functions without the need to configure flags for set commands (/FLAGS=SETS) and authentication traps (/FLAGS=AUTHEN_TRAPS). Note that when you enter the SHOW CONFIGURATION SNMP command, the keywords associated with these flags are displayed as follows:

  Flags: AuthenTraps Sets

• The /FLAGS=SETS qualifier is required to enable SNMP client set command requests. If set commands are not enabled, the client receives a " no such variable " message, even if access type requirements are met. (See the command guidelines in Section 14.6.5.1.)
• The /FLAGS=AUTHEN_TRAPS qualifier allows the SNMP master to send trap messages to specified trap community addresses when MIB access with a community name is not supported by the agent. This also allows the master to send trap messages when the agent does not grant the host the access required for a request (for example, READ for a get request or WRITE for a set request).

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

TCPIP> SET CONFIGURATION SNMP/FLAGS=(SETS,AUTHEN_TRAPS)

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.

14.6.5.2 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:

TCPIP> SET CONFIGURATION /FLAGS=NOSETS

TCPIP> SET CONFIGURATION /FLAGS=NOAUTHEN_TRAPS

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:

$ TYPE SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT

trap      V1 elmginkgo 15.9.0.200
community     alternate 15.4.3.2 read
community         public  0.0.0.0 read
community         TRAPIT 1.2.4.5 write
trap      v2c     TRAPIT 1.2.4.5
community         rw     10.1.1.3       write
community         rw     15.9.0.200     write

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

TCPIP> SHOW CONFIGURATION SNMP/FULL

Community           Type           Address_list

public              Read           0.0.0.0

TRAPIT              Read Write Trap
                                   1.2.4.5

rw                  Read Write     10.1.1.3,  15.9.0.200

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:

TCPIP> SHOW CONFIGURATION SNMP/FULL

SNMP Configuration

Flags:    Sets

Contact:  not defined

Location: not defined

To remove a previously specified location, enter:

TCPIP> SET CONFIGURATION SNMP /LOCATION=(NOFIRST,NOSECOND)

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.

14.6.5.2.2 Verifying Community Information

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

TCPIP> SHOW CONFIGURATION SNMP /FULL

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:

• One of conditions listed above has not been met.
• The commmunity name is invalid. Check to make sure uppercase or lowercase letters are specified correctly. Community names are case sensitive.
• SNMP is not running on the system.
• There are network, delay, or timeout problems.
• The community address was specified incorrectly.
• Communities with write access are not defined on the server.
• The "public" community configuration was not specified as /TYPE=READ with address 0.0.0.0.
• The SNMP configuration is correct, but SNMP was not restarted after changes were made.

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:

• community specifies the community name.
• IP-address specifies the IP address of host that is listening for traps.
• port specifies the port number. The default port number is 162.

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 120.2.1.2 (community name v1type), and a Version 2 trap to go to the host with the IP address 120.2.2.2 (community name v2type). Both traps will go to the well-known port 162:

trap v1 v1type 120.1.2.1
trap v2c v2type 12.2.2.2

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:

   TCPIP> SHOW INTERFACE

   • If TCP/IP Services is not running, a response similar to the following is displayed:

     %TCPIP-E-INTEERROR, error processing interface request -TCPIP-E-NOTSTARTED, TCP/IP Services is not running

   • If TCP/IP Services is running, a response similar to the following is displayed:

     Packets Interface IP_Addr Network mask Receive Send MTU WE0 126.65.100.68 255.255.0.0 20298 5 1500 WF0 126.65.100.108 255.255.0.0 20290 2 4470 LO0 127.0.0.1 255.0.0.0 3290 3290 0

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:

   TCPIP> SHOW NAME_SERVICE

   
   Refer to Chapter 6 for information about configuring the BIND resolver.
3. Check the status of the SNMP service using the following DCL command:

   SHOW LOGICAL/TABLE=TCPIP$STARTUP_TABLE.

   
   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:
   • Confirm the community configuration, as described in Section 14.6.5.2.2. Make sure the default community is configured correctly. For example, make sure that a read-only community name, such as "public," is not being used for set requests. For more information about community names, refer to the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.
   • Check to make sure the client used the correct query format.
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:

   $ SHOW SYSTEM

   
   Check for the following processes:
   • TCPIP$SNMP_n (master agent)
   • TCPIP$OS_MIBS (standard subagent)
   • TCPIP$HR_MIB (standard subagent)
   
   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:
   SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM.
   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:
   • No devices are mounted through NFS.
   • Access to mount information is not available because the proxy is not set up to allow the TCPIP$HR_MIB subagent to access NFS-mounted disks.
   
   Additional problems occur if file protections or installation privileges were changed on SYS$SYSTEM:TCPIP$HR_MIB.EXE.