NetBSD/dist/ntp/html/confopt.htm

216 lines
9.7 KiB
HTML

<html><head><title>
Configuration Options
</title></head><body><h3>
Configuration Options
</h3><hr>
<h4>Configuration Support</h4>
<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,
their effect in some weird mode combinations can be meaningless
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>
<dl>
<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>
</dl>
<h4>Bugs</h4>
<p>The syntax checking is not picky; some combinations of ridiculous and
even hilarious options and modes may not be detected.
<hr><a href=index.htm>Home</a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>