| Previous | Contents | Index |
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:
| Agent | Process | SYS$OUTPUT | SYS$ERROR |
|---|---|---|---|
| Master agent | TCPIP$SNMP | TCPIP$SNMP_RUN.LOG | TCPIP$SNMP_RUN.LOG |
| Resident subagent | TCPIP$SNMP | TCPIP$SNMP_RUN.LOG | TCPIP$SNMP_RUN.LOG |
| OS_MIBS 1 | TCPIP$OS_MIBS | TCPIP$OS_MIBS.LOG | TCPIP$OS_MIBS.ERR |
| HR_MIB | TCPIP$HR_MIB 1 | TCPIP$HR_MIB.LOG | TCPIP$HR_MIB.ERR |
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 |
|---|---|---|
| Master agent | TCPIP$SNMP | TCPIP$ESNMP_SERVER process-ID.LOG |
| Resident subagent | TCPIP$SNMP | TCPIP$ESNMP_RESIDENT_SUBAGENT process-ID.LOG |
| OS_MIBS | TCPIP$OS_MIBS | TCPIP$OS_MIBS process-ID.LOG |
| HR_MIB | TCPIP$HR_MIB | TCPIP$HR_MIB process-ID.LOG |
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:
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:
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:
$ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN |
$ MCR TCPIP$ESNMP_SERVER -T $ MCR TCPIP$OS_MIBS -TRACE $ MCR TCPIP$HR_MIB -TRACE |
$ 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:
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:
Flags: AuthenTraps Sets |
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) |
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.
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:
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 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:
TCPIP> SHOW INTERFACE |
%TCPIP-E-INTEERROR, error processing interface request -TCPIP-E-NOTSTARTED, TCP/IP Services is not running |
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
|
TCPIP> SHOW NAME_SERVICE |
SHOW LOGICAL/TABLE=TCPIP$STARTUP_TABLE. |
WARNING: select returned -1 on snmpd sockets: not owner |
$ SHOW SYSTEM |
| Previous | Next | Contents | Index |