[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Compaq TCP/IP Services for OpenVMS
Release Notes

B.5.1 Sample NTP Log Files

The following sample shows a standard NTP log file that has no extra logging enabled.

 2 Jul 15:33:37  ntpd version = 4.1.0 
 2 Jul 15:33:37  precision = 976 usec 
 2 Jul 15:33:37  frequency initialized -66.795 from SYS$SPECIFIC:[TCPIP$NTP] 
   TCPI P$NTP.DRIFT 
 2 Jul 15:37:01  time slew 0.148981 s 
 2 Jul 16:33:38  offset: 0.008022 sec  freq: 1.301 ppm  poll: 128 sec  error: 
   0.014056 
 2 Jul 17:33:41  offset: 0.003190 sec  freq: 4.218 ppm  poll: 256 sec  error: 
   0.007071 
 2 Jul 18:33:41  offset: -0.000622 sec  freq: 4.575 ppm  poll: 512 sec  error: 
   0.005358 
 2 Jul 19:33:41  offset: -0.003216 sec  freq: 3.749 ppm  poll: 1024 sec  error: 
   0.005610 
 2 Jul 20:33:41  offset: -0.000899 sec  freq: 2.823 ppm  poll: 1024 sec  error: 
   0.005710 
 2 Jul 21:33:41  offset: -0.000299 sec  freq: 2.510 ppm  poll: 1024 sec  error: 
   0.005468 
 2 Jul 22:08:04  time slew -0.156010 s 
 2 Jul 22:33:41  offset: 0.002615 sec  freq: 4.022 ppm  poll: 1024 sec  error: 
   0.005297 
 2 Jul 23:33:41  offset: -0.002466 sec  freq: 3.237 ppm  poll: 1024 sec  error: 
   0.005626 
 3 Jul 00:33:41  offset: 0.000100 sec  freq: 1.737 ppm  poll: 1024 sec  error: 
   0.006343 
 3 Jul 01:33:41  offset: 0.002842 sec  freq: 2.393 ppm  poll: 1024 sec  error: 
   0.006023 
 3 Jul 02:33:41  offset: 0.000089 sec  freq: 3.204 ppm  poll: 1024 sec  error: 
   0.006199 
 3 Jul 03:33:41  offset: 0.001094 sec  freq: 3.576 ppm  poll: 1024 sec  error: 
   0.005628

The next sample shows an NTP log file with all categories of logging enabled.

10 Jul 13:38:05  ntpd version = 4.1.0 
10 Jul 13:38:05  precision = 976 usec 
10 Jul 13:38:05  frequency initialized 3.157 from SYS$SPECIFIC:[TCPIP$NTP]TCPIP$ 
NTP.DRIFT 
10 Jul 13:38:05  system event 'event_restart' (0x01) status 'sync_alarm, sync_un 
spec, 1 event, event_unspec' (0xc010) 
10 Jul 13:38:11  peer 204.123.2.70 event 'event_reach' (0x84) status 'unreach, c 
onf, 1 event, event_reach' (0x8014) 
10 Jul 13:38:20  peer 204.123.2.71 event 'event_reach' (0x84) status 'unreach, c 
onf, 1 event, event_reach' (0x8014) 
10 Jul 13:38:22  peer 16.140.0.12 event 'event_reach' (0x84) status 'unreach, co 
nf, 1 event, event_reach' (0x8014) 
10 Jul 13:39:40  system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, 
sync_ntp, 2 events, event_restart' (0xc621) 
10 Jul 13:39:49  system event 'event_sync_chg' (0x03) status 'leap_none, sync_nt 
p, 3 events, event_peer/strat_chg' (0x634) 
10 Jul 13:39:49  system event 'event_peer/strat_chg' (0x04) status 'leap_none, s 
ync_ntp, 4 events, event_sync_chg' (0x643) 
10 Jul 13:51:24  peer 16.141.40.135 event 'event_reach' (0x84) status 'unreach, 
conf, 1 event, event_reach' (0x8014) 
10 Jul 14:02:08  peer 16.141.40.135 event 'event_unreach' (0x83) status 'unreach 
, conf, 2 events, event_unreach' (0x8023) 
10 Jul 14:12:47  peer 16.141.40.135 event 'event_reach' (0x84) status 'unreach, 
conf, 3 events, event_reach' (0x8034) 
10 Jul 14:38:06  offset: 0.015558 sec  freq: 4.407 ppm  poll: 128 sec  error: 0. 
008575 
10 Jul 14:45:54  peer 16.141.40.135 event 'event_unreach' (0x83) status 'unreach 
, conf, 4 events, event_unreach' (0x8043) 
10 Jul 15:38:07  offset: 0.021501 sec  freq: 8.734 ppm  poll: 512 sec  error: 0. 
015413 
10 Jul 15:44:47  peer 16.141.40.135 event 'event_reach' (0x84) status 'unreach, 
conf, 5 events, event_reach' (0x8054) 
10 Jul 16:38:07  offset: 0.016173 sec  freq: 25.014 ppm  poll: 1024 sec  error: 
0.011453 
10 Jul 17:38:07  offset: -0.043169 sec  freq: 13.291 ppm  poll: 1024 sec  error: 
 0.024752 
10 Jul 18:38:07  offset: -0.017786 sec  freq: 6.005 ppm  poll: 1024 sec  error: 
0.025309

B.6 NTP Authentication Support

Authentication support is implemented using the MD5 algorithm to compute a message digest. The servers involved in an association must agree on the key and key identifier used to authenticate their messages.

Keys and related information are specified in a key file. Keys are used for:

Ordinary NTP associations
The NTPQ utility program
The NTPDC utility program

B.6.1 NTP Authentication Commands

Table B-3 describes additional configuration statements and options that support authentication.

**Table B-3 Authentication Commands**
Command	Description
`keys` keys-file	Specifies the file name for the keys file, which contains the encryption keys and key identifiers used by NTP, NTPQ, and NTPDC when operating in authenticated mode.
`trustedkey` key-ID [...]	Specifies the encryption key identifiers that are trusted for the purposes of authenticating peers suitable for synchronization, as well as keys used by the NTPQ and NTPDC programs. The authentication procedures require that the local and remote servers share the same key-ID and key value for this purpose, although different key values can be used with different servers. The key-ID arguments are 32-bit unsigned decimal integers from 1 to 15. Note that the NTP key 0 is used to indicate an invalid key value or key identifier; therefore, it should not be used for any other purpose.
`requestkey` key-ID	Specifies the key identifier to use with the NTPDC program, which uses a proprietary protocol specific to this implementation of NTP. This program is useful in diagnosing and repairing problems that affect the operation of NTP. For information about NTPDC, see Section B.7.3. The key-ID argument to this command is an unsigned 32-bit decimal number that identifies the trusted key in the keys file. If the `requestkey` command is not included in the configuration file, or if the keys do not match, any request to change a server variable is denied.
`controlkey` key-ID	Specifies the key identifier to use with the NTPQ program, which uses the standard protocol defined in RFC 1305. This program is useful in diagnosing and repairing problems that affect the operation of NTP. For more information about NTPQ, see Section B.7.4. The key-ID argument to this command is a 32-bit decimal integer that identifies a trusted key in the keys file. If the `controlkey` command is not included in the configuration file, or if the keys do not match, any request to change a server variable is denied.

Keys are defined in a keys file, as described in Section B.6.2.

B.6.2 Authentication Key Format

The NTP service reads keys from a keys file that is specified using the keys command in the configuration file. You can supply one or more keys from 1 to 15 in the keys file.

Key entries use the following format:

key-ID key-type key-value

The fields include:

key-ID, which is an arbitrary, unsigned 32-bit number (in decimal). The range of possible values is 1 to 15. Key IDs are specified by the requestkey and controlkey statements in the configuration file. The key ID number 0 (56 zero bits) is reserved; it is used to indicate an invalid key ID or key value.
key-type, which identifies the type of key value. Only one key format, M, is currently supported. This indicates that the MD5 authentication scheme is being used.
key-value, which is an ASCII string from one to eight characters. The following characters are not allowed:
space
pound sign (#)
\t
\n
\0

Because this file contains authorization data, Compaq recommends that you limit read access to this file. In particular, you should disable world read access.

The following is a sample keys file:

   # 
   # 
   4       M    DonTTelL 
   6       M    hElloWrl 
   12      M    ImASecrt

B.7 NTP Utilities

NTP provides several utility programs that help you manage and make changes to the NTP server. These utilities include:

NTPDATE, the date and time utility that sets the local date and time by polling the specified server. Run NTPDATE manually or from the host startup script to set the clock at boot time before NTP starts.
NTPDATE does not set the date if NTP is already running on the same host.
For information about using NTPDATE, see Section B.7.1.
NTPTRACE, the trace utility that follows the chain of NTP servers back to their master time source. For information about using NTPTRACE, see Section B.7.2.
NTPDC, the special query program that provides extensive state and statistics information and allows you to set configuration options at run time. Run this program in interactive mode or with command line arguments.
For information about using NTPDC, see Section B.7.3.
NTPQ, the standard query program that queries NTP servers about their current state and requests changes to that state.
For information about using NTPQ, see Section B.7.4.
NTP_GENKEYS, the random key generator program that generates random keys that are used by the NTP Version 3 and NTP Version 4 symmetric key authentication scheme.
For information about using NTP_GENKEYS, see Section B.7.5.
To define the commands described in the following sections, run the following procedure:
$ @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM

B.7.1 Setting the Date and Time with NTPDATE

The NTPDATE program sets the local date and time by polling a specified server or servers to determine the correct time. A number of samples are obtained from each of the servers specified, and a subset of the NTP clock filter and selection algorithms are applied to select the best samples. The accuracy and reliability of NTPDATE depends on the number of servers it polls, the number of polls it makes each time it runs, and the interval length between runs.

Run NTPDATE manually to set the host clock or from the host startup file to set the clock at boot time. In some cases, it is useful to set the clock manually before you start NTP. The NTPDATE program makes time adjustments (called "stepping the time") by calling the OpenVMS routine SYS$SETIME.

Note

NTPDATE does not set the date and time if an NTP server is running on the same host.

Enter specific commands using the following format:

NTPDATE [option...] host [host...]

For example, the following command sets the clock based on the time provided from one of the specified hosts (BIRDY, OWL, or FRED):

$ NTPDATE BIRDY OWL FRED

NTP sets the date and time by polling the servers you specify as arguments to the command. Samples are obtained from each of the specified servers. NTP then analyzes the results to select the best server to use as a time source. Table B-4 describes the NTPDATE command options.

**Table B-4 NTPDATE Options**
Option	Description
`-d`	Changes the time and prints information useful for debugging.
`-o version`	Specifies the NTP version (1, 2, or 3) for outgoing packets (for compatibility with older versions of NTP). Version 4 is the default.
`-p n`	Specifies the number of samples NTPDATE acquires from each server. The default is 4. You can specify from 1 to 8.
`-q`	Specifies a query only; does not set the clock.

B.7.2 Tracing a Time Source with NTPTRACE

Use the NTPTRACE utility to determine the source from which an NTP server obtains its time. NTPTRACE follows the chain of time servers back to the master time source.

Use the following syntax when entering commands:

NTPTRACE [option...]

The following example shows output from an NTPTRACE command. In the following example, the chain of servers is from the local host to the stratum 1 server FRED, which is synchronizing to a GPS reference clock.

 
$ NTPTRACE 
 
LOCALHOST: stratum 3, offset -0.000000, synch distance1.50948 
parrot.birds.com: stratum 2, offset -0.126774, synch distance 0.00909 
fred.birds.com: stratum 1, offset -0.129567, synch distance 0.00168, 
refid 'GPS'

All times are in seconds. The output fields on each line are as follows:

Host name
Host stratum
Time offset between the host and the local host (not always zero for LOCALHOST).
Synchronization distance
Reference clock ID (only for stratum 1 servers)

Table B-5 describes the NTPTRACE command options.

**Table B-5 NTPTRACE Options**
Option	Description
`-d`	Enables debugging output.
`-n`	Displays IP addresses instead of host names. This may be necessary if a name server is down.
`-r retries`	Sets the number of retransmission attempts for each host. The default is 5.
`-t timeout`	Sets the retransmission timeout (in seconds). The default is 2.
`-v`	Displays additional information about the NTP servers.

B.7.3 Making Run-Time Requests with NTPDC

You can make run-time changes to NTP with query commands by running the NTPDC utility. NTPDC displays time values in seconds.

Run-time requests are always authenticated requests. Authentication not only provides verification that the requester has permission to make such changes, but also gives an extra degree of protection against transmission errors.

The reconfiguration facility works well with a server on the local host and between time-synchronized hosts on the same LAN. The facility works poorly for more distant hosts. Authenticated requests include a timestamp. The server compares the timestamp to its receive timestamp. If they differ by more than a small amount, the request is rejected for the following reasons:

To make it more difficult for an intruder to overhear traffic on your LAN.
To make it more difficult for topologically remote hosts to request configuration changes to your server.

To run NTPDC, enter the following command:

$ NTPDC 
NTPDC>

At the NTPDC> prompt, enter the appropriate type of command from the following list:

Interactive commands
Control commands
Run-time configuration request commands

The following sections describe the NTPDC commands.

B.7.3.1 NTPDC Interactive Commands

Interactive commands consist of a command name followed by one or more keywords. The interactive commands include:

help [command-keyword]
Enter a question mark (?) to display a list of all the command keywords known to this version of NTPDC. Enter a question mark followed by a command keyword to d