[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here >

Compaq TCP/IP Services for OpenVMS
Release Notes


Previous Contents

B.7.3.3 NTPDC Request Commands

The following commands make authenticated requests:

  • addpeer peer-address key-ID [version] [prefer]
    Adds a configured peer association at the given address and operates in symmetric active mode. The existing association with the same peer can be deleted when this command is executed or can be converted to conform to the new configuration.
    The key-ID is the key identifier for requestkey , as described in Table B-3. All outgoing packets to the remote server will have an authentication field attached that is encrypted with this key.
    The value for version can be 1, 2, 3 or 4. The default is Version 4.
    The prefer keyword indicates a preferred peer that will be used for clock synchronization, if possible.
  • addserver peer-address key-ID [version] [prefer]
    This command is the same as addpeer except that the operating mode is client.
  • broadcast peer-address key-ID [version] [prefer]
    This command is the same as addpeer except that the operating mode is broadcast. In this case, a valid key identifier and key value are required. The peer-address parameter can be either the broadcast address of the local network or a multicast group address assigned to NTP.
  • unconfig peer-address [...]
    Causes the configured bit to be removed from the specified remote peer. This deletes the peer association. When appropriate, however, the association may persist in an unconfigured mode if the remote peer is willing to continue in this fashion.
  • enable [flag] [...]
    disable [flag] [...]
    These commands operate in the same way as the enable and disable configuration commands. For details, see Section B.3.2.
  • fudge peer-address [time1] [time2] [stratum stratum] [refID]
    Provides a way to set time, stratum, and identification data for a reference clock. (The TCP/IP Services product supports only the local reference clock.)

Use the following syntax to enter the NTPDC foreign command:


NTPDC [-i] [-l] [-n] [-p] [-s] [-c command][host1,host2,...] 

Table B-6 describes the NTPDC options.

Table B-6 NTPDC Options
Option Description
-c command The command argument is interpreted as an interactive format command and is added to the list of commands to be executed on the specified hosts. You can specify multiple -c options.
-i Forces NTPDC to operate in interactive mode.
-l Obtains a list of peers that are known to the servers.
-n Displays all host addresses in numeric format rather than convert them to host names.
-p Displays a list of the peers known to the server as well as a summary of their state.
-s Displays a list of the peers known to the server as well as a summary of their state. Uses a slightly different format than the -p option.

B.7.4 Querying the NTP Server with NTPQ

The NTPQ program allows you to query the NTP server about its current state and to request changes to that state. NTPQ can also obtain and display a list of peers in a common format by sending multiple queries to the server.

The NTPQ program authenticates requests based on the key entry in the keys file that is configured using the controlkey command (described in Table B-3).

The NTPQ program uses NTP mode 6 packets to communicate with the NTP server; therefore, NTPQ can query any compatible server on the network. Because NTP is a UDP protocol, this communication is somewhat unreliable over long distances (in terms of network topology). The NTPQ program makes one attempt to restransmit requests and times out requests if the remote host does not respond within the expected amount of time. NTPQ displays time values in milliseconds.

To run the NTPQ program, enter the following command:


$ NTPQ 
NTPQ> 

At the NTPQ> prompt, enter commands in the following syntax:


command [options...] 

The following commands allow you to query and set NTP server state information:

  • ? [command-keyword]
    A question mark (?) by itself prints a list of all the command keywords known to this version of NTPQ. A question mark followed by a command keyword prints function and usage information about the command.
  • addvars variable-name[=value] [,...]
  • rmvars variable-name [,...]
  • clearvars
    The data carried by NTP mode 6 messages consists of a list of items in the following form:


    variable-name=value
    

    In requests to the server to read variables, the =value portion is ignored and can be omitted. The NTPQ program maintains an internal list in which data to be included in control messages can be assembled and sent using the readlist and writelist commands. The addvars command allows variables and their optional values to be added to the list. If you want to add more than one variable, separate the list items by commas and do not include blank spaces. The rmvars command removes individual variables from the list, while the clearvars command removes all variables from the list.
  • authenticate yes | no
    By default, NTPQ does not authenticate requests unless they are write requests. The authenticate yes command causes NTPQ to send authentication with all requests it makes. Authenticated requests cause some servers to handle requests slightly differently. To prevent any mishap, do a peer display before turning on authentication.
  • cooked
    Reformats variables that are recognized by the server. Variables that NTPQ does not recognize are marked with a trailing question mark (?).
  • debug more | less | no
    Adjusts the level of NTPQ debugging. The default is debug no .
  • help
    Displays the list of NTPQ interactive commands. This is the same as question mark (?).
  • host [host-name]
    Sets the host to which future queries will be sent; host-name can be either a host name or an Internet address. If host-name is not specified, the current host is used.
  • hostnames yes | no
    If yes is specified, displays host names in information displays. If no is specified, displays Internet addresses instead. The default is hostnames yes . The default can be modified using the command line option -n .
  • key-ID n >B.8 Solving NTP Problems

    Some common NTP problems include:

    • System clock not synchronized.
      NTP cannot synchronize a clock that is off by more than 1000 seconds. To solve this problem, set the clock using NTPDATE, then restart NTP.
    • NTPDATE fails to set the clock.
      This occurs if NTP is already running.
    • More than one service is actively setting the system clock.
      NTP can run with other time services but must be explicitly instructed not to set the system clock. NTP can still provide synchronization to other clients even if it is not updating the system clock.
    • NTP appears to be running without error, but the system clock is off by a one-, two-, three-, or four-hour interval.
      You might need to adjust the time zone differential. For more information, please consult the OpenVMS documentation set.

    B.8.1 NTP Debugging Techniques

    Once the configuration file has been created and edited, the next step is to verify correct operation and then fix any problems that might have resulted.

    B.8.1.1 Initial Startup

    The best way to verify correct operation is by using the NTPQ and NTPDC programs, either on the server itself or from another machine elsewhere in the network. The NTPQ program implements the management functions specified in the NTP specification RFC 1305, Appendix A. The NTPDC program implements additional functions not provided in the standard. Both programs can be used to inspect the state variables defined in the specification and, in the case of NTPDC, additional ones of interest. In addition, the NTPDC program can be used to selectively reconfigure and enable or disable some functions while the server is running. Problems are apparent in the server's log file. The log file should show the startup banner, some brief initialization data, and the computed precision value.

    Another common problem is incorrect DNS names. Check that each DNS name used in the configuration file exists and that the address responds to the ping command. When the server is first started it normally polls the servers listed in the configuration file at 64-second intervals. To allow a sufficient number of samples for the NTP algorithms to discriminate reliably between correctly operating servers and possible intruders, at least four valid messages from the majority of servers and peers listed in the configuration file are required before the server can set the local clock. However, if the difference between the client time and server time is greater than the panic threshold (which defaults to 1000 seconds), the server sends a message to the server log and shuts down without setting the clock. It is necessary to set the local clock to within the panic threshold first, either manually by wristwatch and the SET TIME command, or by using the NTPDATE command. The panic threshold can be changed by the tinker panic statement.


    Previous Next Contents