|
>
Compaq TCP/IP Services for OpenVMS Release
Notes
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:
At the NTPQ> prompt, enter commands in the following syntax:
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:
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.
|