When nothing seems to happen in the peer display after several minutes, it might indicate a network problem. One common network problem is an access-controlled router on the path to the selected peer, or an access-controlled server using methods described in Section 13.4.2.2. Another common problem is that the server is down or is running in unsynchronized mode because of a local problem. Use the NTPQ program to look at the server variables in the same way you look at your own.

13.10.1.3 Special Problems

The frequency tolerance of computer clock oscillators can vary widely, which can put a strain on the server's ability to compensate for the intrinsic frequency error. While the server can handle frequency errors up to 500 parts per million (ppm), or 43 seconds per day, values much higher than 100 ppm reduce the headroom and increase the time to identify the particular value and record it in the TCPIP$NTP.DRIFT file. In extreme cases, before the particular oscillator frequency error has been determined, the residual system time offsets can sweep from one extreme to the other of the 128-millisecond tracking window only for the behavior to repeat at 900-second intervals until the measurements have converged.

To determine whether excessive frequency error is occurring, observe the nominal filtoffset values for a number of rounds and divide by the poll interval. If the result is approximately 500 ppm, NTP probably will not work properly until the frequency error is reduced.

A common cause of this problem is the hardware time-of-year (TOY) clock chip, which must be disabled when NTP disciplines the software clock.

If the TOY chip is not the cause, the problem might be that the hardware clock frequency is too slow or too fast.

NTPD provides for access controls that deflect unwanted traffic from selected hosts or networks. The controls described in Section 13.4.2.2 include detailed packet filter operations based on source address and address mask. Normally, filtered packets are dropped without notice other than to increment tally counters. However, the server can be configured to generate a kiss-of-death (kod) packet to be sent to the client. If outright access is denied, the kod is the response to the first client packet. In this case, the client association is permanently disabled and the access-denied bit is set in the flash peer variable, and a message is sent to the server's log file.

The access control provisions include a limit on the packet rate from a host or network. If an incoming packet exceeds the limit, it is dropped and a kod is sent to the source. If this occurs after the client association has synchronized, the association is not disabled, but a message is sent to the system log. For more information, see Section 13.4.2.2.

13.10.1.4 Debugging Checklist

If the NTPQ or NTPDC programs do not show that messages are being received by the server or that received messages do not result in correct synchronization, verify the following:

1. Check the TCPIP$NTP_RUN.LOG log file for messages about configuration errors, name lookup failures, or initialization problems.
2. Using ping or other utilities,verify that packets actually do make the round trip between the client and server. Using dig or other utilities, verify that the DNS server names do exist and resolve to valid Internet addresses.
3. Using the NTPDC program, verify that the packets received and packets sent counters are incrementing. If the sent counter does not increment and the configuration file includes configured servers, something might be wrong in the host network or the interface configuration. If this counter does increment but the received counter does not increment, something might be wrong in the network, the remote server NTP server might not be running, or the server itself might be down or not responding.
4. If both the sent and received counters do increment but the reach values in the peer display with NTPQ continues to show zero, received packets are probably being discarded. If this is the case, the cause should be evident from the flash variable.
5. If the reach values in the peer display show that the servers are alive and responding, note the symbols at the left margin that indicate the status of each server resulting from the various grooming and mitigation algorithms. After a few minutes of operation, one of the reachable server candidates should show an asterisk (*). If this does not happen, the intersection algorithm, which classifies the servers as "truechimers" or "falsetickers", might be unable to find a majority of "truechimers" among the server population.

The Simple Network Management Protocol (SNMP) is network management technology that facilitates the management of a TCP/IP network or internet in a vendor-independent manner. SNMP enables a network administrator to manage the various network components using a set of well-known procedures understood by all components, regardless of the vendor that manufactured them.

Configuring SNMP on your OpenVMS system allows a remote SNMP management client to obtain information about your host and to set system and network parameters.

This chapter reviews key concepts of SNMP and describes:

• How to manage the SNMP service ( Section 14.2)
• How to verify the installation of SNMP ( Section 14.3)
• How to configure SNMP ( Section 14.4)
• SNMP log files ( Section 14.5)
• How to solve SNMP problems ( Section 14.6)

For information about writing programs using SNMP, refer to the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

14.1 Key Concepts

Systems using SNMP are divided into two categories:

• Management consoles, sometimes called clients, network management stations, or directors
• Agents, sometimes called servers

The management console is the system that issues a query; the agents run on the system being queried. Queries are sent and received in the form of protocol data units (PDUs) inside SNMP messages, which are carried in user data protocol (UDP) datagrams.

You can configure your host so that an SNMP client can obtain information about your host and perform updates on your host's management information base (MIB) data items. For example, you can configure your host to:

• Respond to a client's read requests ("gets") for network information.
• Process client write requests ("sets") on your host's MIB data items.
• Send alert messages ("traps") to a client as a result of events that might need to be monitored (for example, an authentication failure).

TCP/IP Services provides an SNMP master agent, two subagents (MIB II and Host Resources MIB), a MIB converter and compiler, a simple MIB browser, and MIB utility programs. Each subagent contains routines that perform read and write operations on its MIB data items.

Table 14-1 describes the SNMP components and the sample code supplied for custom subagent development.

Table 14-1 SNMP Components

Component	Description
Master agent SNMP Version 2	Process name: TCPIP$SNMP_ n, where n is the number of times that the master agent has been started since the SNMP service was enabled. Keeps track of managed objects and allows objects to register themselves. Sends information about these objects to remote SNMP management consoles. Also maintains a small set of variables for the MIB II component.
MIB II	Process name: TCPIP$OS_MIBS. Provides information about the TCP/IP protocol stack and other network activity.
Host resources MIB	Process name: TCPIP$HR_MIB. Provides information about the host system.
MIB converter	Extracts a MIB definition in ASN.1 notation into a MIB definition (.MY) file.
MIB compiler	Compiles MIB-definition files (for example, CHESS_MIB.MY) into source code templates for use in building subagents.
SNMP utility programs	Acts as a simple clients to obtain a set of values for a MIB and to listen for and send trap messages. For information about using the MIB utility programs, see the HP TCP/IP Services for OpenVMS SNMP Programming and Reference manual.
SNMP subagent example	Implements an example based on the chess game; includes executable and source code.

14.1.1 Understanding How SNMP Operates

The TCPIP$CONFIG procedure sets up the SNMP UDP-based service at well-known port 161.

In addition, TCPIP$CONFIG sets up required files in the SYS$SYSDEVICE:[TCPIP$SNMP] directory.

The SNMP startup procedure (SYS$STARTUP:TCPIP$SNMP_STARTUP.COM) runs from the general TCPIP$STARTUP.COM procedure or can be run directly by the system manager.

TCPIP$SNMP_STARTUP.COM does the following:

1. Checks the TCP/IP Services license and enables the SNMP service.
2. Installs images with the required privileges (as appropriate: BYPASS, PHY_IO, and WORLD).
3. Runs SYS$STARTUP:TCPIP$SNMP_SYSTARTUP.COM.

To ensure compatibility with previous versions of TCP/IP Services, TCPIP$SNMP_SYSTARTUP.COM in turn runs SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_STARTUP.COM, which installs and adjusts privileges for any additional, user-written subagents.

On startup, the TCP/IP Services kernel runs the TCPIP$SYSTEM:TCPIP$SNMP_RUN.COM procedure, which does the following:

• Purges log files in the SYS$SYSDEVICE:[TCPIP$SNMP] directory.
• Runs the subagent image as a detached process.
• Runs SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM to start any additional subagents.

As each subagent starts, it makes itself known to the master agent, a sequence that includes registering the MIB subtrees that the subagent maintains and communicating the port number on which it listens.

Once SNMP starts, the following sequence occurs for each incoming SNMP request. This sequence is standard for SNMP implementations.

1. The master agent listens for incoming SNMP requests from clients on port 161. Authentication is limited to the validation of the community name. When a request arrives, the master agent communicates with the appropriate subagent.
2. Subagent routines collect the requested data and return the data to the master agent.
3. The master agent responds to the client from which the original request was made.

The SNMP shutdown procedure TCPIP$SNMP_SHUTDOWN.COM runs either from the general shutdown procedure TCPIP$SHUTDOWN.COM or can be run directly by the system manager.

TCPIP$SNMP_SHUTDOWN.COM does the following:

• Stops subagent processes and removes the SNMP images.
• Runs the SYS$STARTUP:TCPIP$SNMP_SYSHUTDOWN.COM procedure.

To ensure compatibility with previous versions, this procedure in turn runs SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_SHUTDOWN.COM, which stops any additional subagent processes and deinstalls their images, if necessary.

14.1.2 Ensuring Access to Mounted Data

If the proxy setup between the SNMP server and the NFS server is not correct, the Host Resources MIB subagent cannot access data that has been mounted.

To ensure access to mounted data, set up a proxy to an anonymous user (for example, to TCPIP$NOBODY) on the NFS server system. For more information about adding proxy entries, see Chapter 22.

14.2 Managing the SNMP Service

The following command procedures are supplied to allow you to start up and shut down the SNMP service independently of TCP/IP Services:

• SYS$STARTUP:TCPIP$SNMP_STARTUP.COM allows you to start up the SNMP service.
• SYS$STARTUP:TCPIP$SNMP_SHUTDOWN.COM allows you to shut down the SNMP service.

Both the startup and shutdown procedures invoke the appropriate TCPIP$EXTENSION_MIB_*.COM file to ensure compatibility with previous versions of TCP/IP Services.

These files might be overwritten when you install subsequent versions of the TCP/IP Services product. For more information about these procedures, see Section 14.1.1.

To maintain site-specific SNMP logical names, commands, and parameter settings, you can create the following files:

• SYS$STARTUP:TCPIP$SNMP_SYSTARTUP.COM can be used as a repository site-specific definitions and parameters to be invoked when SNMP is started.
• SYS$STARTUP:TCPIP$SNMP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when SNMP is shut down.

Enter the commands for starting and stopping site-specific subagents in these command procedures.

14.3 Verifying the SNMP Installation

A separate installation verification procedure (IVP) exists for SNMP. To verify your configuration, complete these steps:

1. Log in to the SYSTEM account, or make sure that your process has the following privileges:
   • TMPMBX
   • NETMBX
   • SETPRV
2. Run the command procedure:

   $ @SYS$MANAGER:TCPIP$CONFIG

3. Enter option 7 (Run tests), and then option 2 from the HP TCP/IP Services for OpenVMS Test menu.
   Note that, like the Internet IVP, the SNMP IVP requires that TCP/IP Services be running. (It does not require that SNMP be running.)
4. To run the SNMP IVP any time after exiting the configuration procedure, enter the following command:

   $ RUN SYS$COMMON:[SYSTEST.TCPIP]TCPIP$SNMPIVP.EXE

Table 14-2 lists the names of the primary SNMP executable and command files and their locations. For a list of files that help you build your own subagent, see the HP TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

Table 14-2 SNMP Executable, Command, and Data Files

File	Location	Function
TCPIP$ESNMP_SERVER.EXE	SYS$SYSTEM	Master agent image.
TCPIP$OS_MIBS.EXE	SYS$SYSTEM	MIB II subagent image.
TCPIP$HR_MIB.EXE	SYS$SYSTEM	Host Resources MIB subagent image.
TCPIP$SNMP_REQUEST.EXE	SYS$SYSTEM	Simple MIB browser.
TCPIP$SNMP_TRAPSND.EXE	SYS$SYSTEM	Program for sending trap messages.
TCPIP$SNMP_TRAPRCV.EXE	SYS$SYSTEM	Program for receiving trap messages.
TCPIP$ESNMP_SHR.EXE	SYS$SHARE	Routines in the eSNMP application programming interface (API).
TCPIP$SNMP_STARTUP.COM	SYS$STARTUP	Installs master and subagent images and runs TCPIP$SNMP_RUN.COM.
TCPIP$SNMP_RUN.COM	TCPIP$SYSTEM	Starts the master agent and subagents.
TCPIP$SNMP_SHUTDOWN.COM	SYS$STARTUP	Stops the master agent and subagents.
TCPIP$SNMP_SYSTARTUP.COM	SYS$STARTUP	Sets site-specific configuration values on startup.
TCPIP$SNMP_SYSHUTDOWN.COM	SYS$STARTUP	Sets site-specific configuration values on shutdown.
TCPIP$EXTENSION_MIB_STARTUP.COM
	SYS$SYSDEVICE:[TCPIP$SNMP]	Starts custom subagents.
TCPIP$EXTENSION_MIB_SHUTDOWN.COM
	SYS$SYSDEVICE:[TCPIP$SNMP]	Shuts down custom subagents.
TCPIP$VMS_SNMP_CONF.DAT	SYS$SYSDEVICE:[TCPIP$SNMP]	User-editable configuration data file.
TCPIP$SNMP_CONF.DAT	SYS$SYSDEVICE:[TCPIP$SNMP]	Configuration data file used in the startup of the master agent and standard subagents.

14.4 Configuring SNMP

You can configure SNMP in three ways, which can be used in combination:

• Using the standard TCPIP$CONFIG.COM procedure and the SET CONFIGURATION SNMP command. These methods write configuration information into the TCP/IP Services configuration database file TCPIP$CONFIGURATION.DAT. Section 14.4.1 describes how to use TCPIP$CONFIG to initially configure SNMP.
• Editing the text configuration file TCPIP$VMS_SNMP_CONF.DAT, located in the SYS$SYSDEVICE:[TCPIP$SNMP] directory. This method provides options not available with TCPIP$CONFIG and with the SET CONFIGURATION SNMP command.

  Note Although the OpenVMS SNMP configuration file is based on the UNIX implementation, there are several important differences. For example, the option snmpEnableAuthenTraps is not used. See the description of specific options for details.

  
  The configuration file is described in Section 14.4.3.
• Assigning logical names. This method provides the same options as the text configuration file. For more information, see Section 14.4.3.

If the same option is defined in multiple ways, the configuration methods are resolved as follows:

• Values specified through TCPIP$CONFIG or SET CONFIGURATION SNMP take precedence over any options specified in the TCPIP$VMS_SNMP_CONF.DAT file or set with logical names.
• Values specified in the TCPIP$VMS_SNMP_CONF.DAT file take precedence over logical name settings.

SNMP runs as a TCP/IP service. To be sure all SNMP-related files are included and enabled properly, run the TCPIP$CONFIG configuration procedure to configure SNMP initially or to set up a new configuration. When you enable SNMP during TCPIP$CONFIG, the procedure prompts you for the correct parameters.

When you run TCPIP$CONFIG after a TCP/IP Services upgrade, be sure to disable and then reenable the SNMP service.

You supply the following information about your host when you configure SNMP initially during TCPIP$CONFIG or when you issue the SET CONFIGURATION SNMP command to modify your existing SNMP configuration. For detailed information about the SET CONFIGURATION SNMP command and qualifiers, see the HP TCP/IP Services for OpenVMS Management Command Reference manual.

• The name of the person to contact about the system. For example:

  TCPIP> SET CONFIGURATION SNMP/CONTACT="Sam Spade"

• The physical location of the system. For example:

  TCPIP> SET CONFIGURATION SNMP - _TCPIP> /LOCATION=(FIRST="Falcon Building",SECOND="Los Angeles, CA")

• The community information used to authenticate requests from a network manager and to determine the addresses to which trap messages are sent.
  SNMP network management clients are grouped into communities as specified in RFC 1157. You can define one or more communities, which your master agent uses to authenticate requests.
  The parameters you specify for each community are as follows:
  • Community name
    The name associated with the community. The standard community is "public." You can choose not to provide this community name when you run TCPIP$CONFIG. Answer no to the question "Do you want to provide the public community." If you disable the public community, you might need to reconfigure SNMP clients in your environment.
    Community names are case sensitive. When you use TCPIP$CONFIG to specify a community name, do not use quotation marks to preserve the case; the case is preserved exactly as you enter it. However, if you customize your existing SNMP configuration using the SET CONFIGURATION SNMP command, make sure you enclose the community name in quotation marks to preserve the case. If you do not enclose the community name in quotation marks, the name is changed to all uppercase.
    The community name must be a string of alphanumeric characters. You cannot include a space or other nonalphanumeric character in the community name.
    You can also modify the community name using the community option in the configuration file, as described in Table 14-4.

  • Community address
    The address associated with the community. One community name can have multiple addresses in its entry. For example:

    TCPIP> SET CONFIGURATION SNMP /ADDRESS=(6.10.1.2,100.2.2.1)

    
    Specifying address 0.0.0.0 for READ and WRITE allows any host the type of access specified. To allow any network manager to monitor your system remotely, specify the standard community name ( public , in lowercase letters) with address 0.0.0.0. For example:

    TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /ADDRESS=0.0.0.0

    
    Traps are sent to UDP port 162 on hosts for all trap addresses regardless of community name. The use of address 0.0.0.0 on a trap means that traps are not sent unless another address is also specified.

  • Types of access
    The types of access associated with the community are described in the following table:

    Access Type	Allows the Master Agent and Subagent to...
    READ	Respond to a client's read requests (gets) for network information. Default. Members of a read-only community do not have write access to the SNMP MIB objects.
    TRAP	Send alert messages (traps) to a client as a result of unusual events. For example, a trap message is sent to the client as a result of a get request that specifies an unauthorized community string ( authenticationFailure ).
    WRITE	Process client write requests (sets) on your host's MIB data items.

For example, to allow the master agent to respond to client get requests, enter:

TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /TYPE=READ

To configure your host to allow client set requests, use the /FLAGS=SETS qualifier. For example:

TCPIP> SET CONFIGURATION SNMP /COMMUNITY="public" /FLAGS=SETS