2000-03-29 16:38:44 +04:00
|
|
|
<html><head><title>
|
|
|
|
Configuration Options
|
|
|
|
</title></head><body><h3>
|
|
|
|
Configuration Options
|
|
|
|
</h3><hr>
|
|
|
|
|
|
|
|
<h4>Configuration Support</h4>
|
|
|
|
|
2000-04-22 18:51:59 +04:00
|
|
|
<p>Following is a description of the configuration commands in NTPv4.
|
|
|
|
These commands have the same basic functions as in NTPv3 and in some
|
|
|
|
cases new functions and new arguments. There are two classes of
|
|
|
|
commands, configuration commands that configure a persistent association
|
|
|
|
with a remote server or peer or reference clock, and auxilliary commands
|
|
|
|
that specify environmental variables that control various related
|
|
|
|
operations.
|
|
|
|
|
|
|
|
<h4>Configuration Commands</h4>
|
|
|
|
|
|
|
|
<p>The various modes are determined by the command keyword and the type
|
|
|
|
of the required IP address. Addresses are classed by type as (s) a
|
|
|
|
remote server or peer (IP class A, B and C), (b) the broadcast address
|
|
|
|
of a local interface, (m) a multicast address (IP class D), or (r) a
|
|
|
|
reference clock address (127.127.x.x). Note that some options are not
|
|
|
|
supported by all these commands while autokey and burst modes are
|
|
|
|
supported by these commands,
|
2000-03-29 16:38:44 +04:00
|
|
|
their effect in some weird mode combinations can be meaningless
|
2000-04-22 18:51:59 +04:00
|
|
|
or even destructive.
|
|
|
|
|
|
|
|
<dl>
|
|
|
|
|
|
|
|
<dt><tt>peer <i>address</i> [key <i>key</i> | autokey | publickey
|
|
|
|
<i>keyfile</i>] [burst] [version <i>version</i>] [prefer] [minpoll
|
|
|
|
<i>minpoll</i>] [maxpoll <i>maxpoll</i>]</tt></dt>
|
|
|
|
|
|
|
|
<p><dt><tt>server <i>address</i> [key <i>key</i> | autokey | publickey
|
|
|
|
<i>keyfile</i>] [burst] [version <i>version</i>] [prefer] [minpoll
|
|
|
|
<i>minpoll</i>] [maxpoll <i>maxpoll</i>] [publickey
|
|
|
|
<i>keyfile</i>]</tt></dt>
|
|
|
|
|
|
|
|
<p><dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey] [burst]
|
|
|
|
[version <i>version</i>] [minpoll <i>minpoll</i>] [maxpoll
|
|
|
|
<i>maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
|
|
|
|
|
|
|
|
<p><dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey |
|
|
|
|
publickey <i>keyfile</i>] [burst] [version <i>version</i>] [minpoll
|
|
|
|
<i>minpoll</i> [maxpoll <i>maxpoll</i>] [ttl <i>ttl</i>] [publickey
|
|
|
|
<i>file</i>]</tt></dt>
|
|
|
|
|
|
|
|
<p><<dd>These four commands specify the time server name or address to
|
|
|
|
be used and the mode in which to operate. The <i>address</i> can be
|
|
|
|
either a DNS name or a IP address in dotted-quad notation. Additional
|
|
|
|
information on association behavior can be found in the <a
|
|
|
|
href="assoc.htm">Association Management</a> page.</dd>
|
|
|
|
|
|
|
|
<dd><dl>
|
|
|
|
|
|
|
|
<dt><tt>server</tt></dt>
|
|
|
|
<dd>For type s and r addresses, this operates as the NTPv3 server
|
|
|
|
command, which mobilizes a persistent client mode association. The
|
|
|
|
<tt>server</tt> command specifies that the local server is to operate in
|
|
|
|
client mode with the specified remote server. In this mode, the local
|
|
|
|
server can be synchronized to the remote server, but the remote server
|
|
|
|
can never be synchronized to the local server.</dd>
|
|
|
|
|
|
|
|
<dt><tt>peer</tt></dt>
|
|
|
|
<dd>For type s addresses (only), this operates as the current <tt>peer
|
|
|
|
</tt>command, which mobilizes a persistent symmetric-active mode
|
|
|
|
association, except that additional modes are available. This command
|
|
|
|
should NOT be used for type <tt>b</tt>, <tt>m</tt> or <tt>r</tt>
|
|
|
|
addresses.</dd>
|
|
|
|
|
|
|
|
<p><dd>The <tt>peer</tt> command specifies that the local server is to
|
|
|
|
operate in symmetric active mode with the remote server. In this mode,
|
|
|
|
the local server can be synchronized to the remote server and, in
|
|
|
|
addition, the remote server can be synchronized by the local server.
|
|
|
|
This is useful in a network of servers where, depending on various
|
|
|
|
failure scenarios, either the local or remote server may be the better
|
|
|
|
source of time.</dd>
|
|
|
|
|
|
|
|
<dt><tt>broadcast</tt></dt>
|
|
|
|
<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this operates
|
|
|
|
as the current NTPv3 <tt>broadcast </tt>command, which mobilizes a
|
|
|
|
persistent broadcast mode association, except that additional modes are
|
|
|
|
available. Multiple commands can be used to specify multiple local
|
|
|
|
broadcast interfaces (subnets) and/or multiple multicast groups. Note
|
|
|
|
that local broadcast messages go only to the interface associated with
|
|
|
|
the subnet specified, but multicast messages go to all interfaces. In
|
|
|
|
the current implementation, the source address used for these messages
|
|
|
|
is the Unix host default address.</dd>
|
|
|
|
|
|
|
|
<p><dd>In broadcast mode, the local server sends periodic broadcast
|
|
|
|
messages to a client population at the <i><tt>address</tt></i>specified,
|
|
|
|
which is usually the broadcast address on (one of) the local network(s)
|
|
|
|
or a multicast address assigned to NTP. The IANA has assigned the
|
|
|
|
multicast group address 224.0.1.1 exclusively to NTP, but other
|
|
|
|
nonconflicting addresses can be used to contain the messages within
|
|
|
|
administrative boundaries.. Ordinarily, this specification applies only
|
|
|
|
to the local server operating as a sender; for operation as a broadcast
|
|
|
|
client, see the <tt>broadcastclient</tt> or <tt>multicastclient</tt>
|
|
|
|
commands below.</dd>
|
|
|
|
|
|
|
|
<dt><tt>manycastclient</tt>
|
|
|
|
<dd>For type <tt>m</tt> addresses (only), this mobilizes a manycast
|
|
|
|
client-mode association for the multicast address specified. In this
|
|
|
|
case a specific address must be supplied which matches the address used
|
|
|
|
on the <tt>manycastserver </tt>command for the designated manycast
|
|
|
|
servers. The NTP multicast address 224.0.1.1 assigned by the IANA should
|
|
|
|
NOT be used, unless specific means are taken to avoid spraying large
|
|
|
|
areas of the Internet with these messages and causing a possibly massive
|
|
|
|
implosion of replies at the sender. </dd>
|
|
|
|
|
|
|
|
<p><dd>The <tt>manycast </tt>command specifies that the local server is
|
|
|
|
to operate in client mode with the remote server that are discovered as
|
|
|
|
the result of broadcast/multicast messages. The client broadcasts a
|
|
|
|
request message to the group address associated with the specified
|
|
|
|
<i><tt>address </tt></i>and specifically enabled servers respond to
|
|
|
|
these messages. The client selects the servers providing the best time
|
|
|
|
and continues as with the <tt>server </tt>command. The remaining servers
|
|
|
|
are discarded as if never heard.</dd>
|
|
|
|
|
|
|
|
</dl>
|
|
|
|
|
|
|
|
<dd>Options</dd>
|
|
|
|
|
|
|
|
<dl><dd>
|
|
|
|
|
|
|
|
<dt><tt>autokey</tt></dt>
|
|
|
|
<dd>All packets sent to and received from the server or peer are to
|
|
|
|
include authentication fields encrypted using the autokey scheme
|
|
|
|
described in the <a href=authopt.htm>Authentication Options</a>
|
|
|
|
page.</dd>
|
|
|
|
<dt><tt>burst</tt></dt>
|
|
|
|
<dd>At each poll interval, send a burst of eight packets spaced, instead
|
|
|
|
of the usual one.</dd>
|
|
|
|
|
|
|
|
<dt><tt>key </tt><i><tt>key</tt></i></dt>
|
|
|
|
<dd>All packets sent to and received from the server or peer are to
|
|
|
|
include authentication fields encrypted using the specified <i>key</i>
|
|
|
|
identifier with values from 1 to 65534, inclusive. The default is to
|
|
|
|
include no encryption field.</dd>
|
|
|
|
|
|
|
|
<dt><tt>minpoll <i>minpoll</i></tt>
|
|
|
|
<br><tt>maxpoll <i>maxpoll</i></tt>
|
|
|
|
<dd>These options specify the minimum and maximum polling intervals for
|
|
|
|
NTP messages, in seconds to the power of two. The default range is 6 (64
|
|
|
|
s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h)
|
|
|
|
inclusive.</dd>
|
|
|
|
|
|
|
|
<dt><tt>prefer</tt></dt>
|
|
|
|
<dd>Marks the server as preferred. All other things being equal, this
|
|
|
|
host will be chosen for synchronization among a set of correctly
|
|
|
|
operating hosts. See the <a href="prefer.htm">Mitigation Rules and the
|
|
|
|
<tt>prefer</tt> Keyword </a>page for further information.</dd>
|
|
|
|
|
|
|
|
<DT><TT>publickey <I>file</I></TT></DT>
|
|
|
|
<DD>This command requires the NTP daemon build process be configured
|
|
|
|
with the RSA library. The command specifies the name of the public key
|
|
|
|
file for the server or peer. The default name for this file is
|
|
|
|
<tt>ntpkey_<i>host</i></tt>, where <i>host</i> is the DNS canonical name
|
|
|
|
of the server or peer. See the <a href=authopt.htm>Authentication
|
|
|
|
Options</a> page for further information.</dd>
|
|
|
|
|
|
|
|
<dt><tt>ttl <i>ttl</i></tt></dt>
|
|
|
|
<dd>This option is used only with broadcast mode. It specifies the
|
|
|
|
time-to-live <i><tt>ttl</tt></i> to use on multicast packets. Selection
|
|
|
|
of the proper value, which defaults to 127, is something of a black art
|
|
|
|
and must be coordinated with the network administrator.</dd>
|
|
|
|
|
|
|
|
<dt><tt>version <i>version</i></tt></dt>
|
|
|
|
<dd>Specifies the version number to be used for outgoing NTP packets.
|
|
|
|
Versions 1-4 are the choices, with version 4 the default.</dd>
|
|
|
|
|
|
|
|
</dl></dd></dl></dd>
|
|
|
|
|
|
|
|
<h4>Auxilliary Commands</h4>
|
2000-03-29 16:38:44 +04:00
|
|
|
|
|
|
|
<dl>
|
2000-04-22 18:51:59 +04:00
|
|
|
|
|
|
|
<dt><tt>broadcastclient</tt>
|
|
|
|
<dd>This command directs the local server to listen for and respond to
|
|
|
|
broadcast messages received on any local interface. Upon hearing a
|
|
|
|
broadcast message for the first time, the local server measures the
|
|
|
|
nominal network delay using a brief client/server exchange with the
|
|
|
|
remote server, then enters the broadcastclient mode, in which it listens
|
|
|
|
for and synchronizes to succeeding broadcast messages. Note that, in
|
|
|
|
order to avoid accidental or malicious disruption in this mode, both the
|
|
|
|
local and remote servers should operate using authentication and the
|
|
|
|
same trusted key and key identifier.</dd>
|
|
|
|
|
|
|
|
<dt><tt>manycastserver <i>address</i> [...]</tt>
|
|
|
|
<dd>This command directs the local server to listen for and respond to
|
|
|
|
broadcast messages received on any local interface, and in addition
|
|
|
|
enables the server to respond to client mode messages to the multicast
|
|
|
|
group address(es) (type m) specified. At least one address is required,
|
|
|
|
but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT
|
|
|
|
be used, unless specific means are taken to limit the span of the reply
|
|
|
|
and avoid a possibly massive implosion at the original sender.</dd>
|
|
|
|
<dt><tt>multicastclient [<i>address</i>] [...]</tt>
|
|
|
|
<dd>This command directs the local server to listen for multicast
|
|
|
|
messages at the group address(es) of the global network. The default
|
|
|
|
address is that assigned by the Numbers Czar to NTP (224.0.1.1). This
|
|
|
|
command operates in the same way as the <tt>broadcastclient</tt>
|
|
|
|
command, but uses IP multicasting. Support for this command requires
|
|
|
|
multicast kernel support.</dd>
|
|
|
|
|
2000-03-29 16:38:44 +04:00
|
|
|
</dl>
|
|
|
|
|
2000-04-22 18:51:59 +04:00
|
|
|
<h4>Bugs</h4>
|
|
|
|
|
|
|
|
<p>The syntax checking is not picky; some combinations of ridiculous and
|
|
|
|
even hilarious options and modes may not be detected.
|
2000-03-29 16:38:44 +04:00
|
|
|
|
2000-04-22 20:46:49 +04:00
|
|
|
<hr><a href=index.htm>Home</a><address><a
|
2000-04-22 18:51:59 +04:00
|
|
|
href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
|
|
|
|
</address></a></body></html>
|