1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
4
<meta name="generator" content="HTML Tidy, see www.w3.org">
5
<title>Configuration Options</title>
8
<h3>Configuration Options</h3>
10
<img align="left" src="pic/boom3a.gif" alt="gif"><a href=
11
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
14
<p>The chicken is getting configuration advice.<br clear="left">
18
<h4>Configuration Support</h4>
20
<p>Following is a description of the configuration commands in
21
NTPv4. These commands have the same basic functions as in NTPv3 and
22
in some cases new functions and new arguments. There are two
23
classes of commands, configuration commands that configure a
24
persistent association with a remote server or peer or reference
25
clock, and auxilliary commands that specify environmental variables
26
that control various related operations.</p>
28
<h4>Configuration Commands</h4>
30
<p>The various modes are determined by the command keyword and the
31
type of the required IP address. Addresses are classed by type as
32
(s) a remote server or peer (IP class A, B and C), (b) the
33
broadcast address of a local interface, (m) a multicast address (IP
34
class D), or (r) a reference clock address (127.127.x.x). Note that
35
only those options applicable to each command are listed below. Use
36
of options not listed may not be caught as an error, but may result
37
in some weird and even destructive behavior.</p>
40
<dt><tt>server <i>address</i> [key <i>key</i> | autokey] [burst]
41
[iburst] [version <i>version</i>] [prefer] [minpoll <i>minpoll</i>]
42
[maxpoll <i>maxpoll</i>]</tt></dt>
44
<dt><tt>peer <i>address</i> [key <i>key</i> | autokey] [version <i>
45
version</i>] [prefer] [minpoll <i>minpoll</i>] [maxpoll <i>
46
maxpoll</i>]</tt></dt>
48
<dt><tt>broadcast <i>address</i> [key <i>key</i> | autokey]
49
[version <i>version</i>] [minpoll <i>minpoll</i>] [ttl <i>
52
<dt><tt>manycastclient <i>address</i> [key <i>key</i> | autokey]
53
[version <i>version</i>] [minpoll <i>minpoll</i> [maxpoll <i>
54
maxpoll</i>] [ttl <i>ttl</i>]</tt></dt>
56
<dd>These four commands specify the time server name or address to
57
be used and the mode in which to operate. The <i>address</i> can be
58
either a DNS name or a IP address in dotted-quad notation.
59
Additional information on association behavior can be found in the
60
<a href="assoc.htm">Association Management</a> page.
63
<dt><tt>server</tt></dt>
65
<dd>For type s and r addresses, this command mobilizes a persistent
66
client mode association with the specified remote server or local
67
radio clock. In this mode the local clock can synchronized to the
68
remote server, but the remote server can never be synchronized to
69
the local clock. This command should NOT be used for type <tt>
70
b</tt> or <tt>m</tt> addresses.</dd>
72
<dt><tt>peer</tt></dt>
74
<dd>For type s addresses (only), this command mobilizes a
75
persistent symmetric-active mode association with the specified
76
remote peer. In this mode the local clock can be synchronized to
77
the remote peer or the remote peer can be synchronized to the local
78
clock. This is useful in a network of servers where, depending on
79
various failure scenarios, either the local or remote peer may be
80
the better source of time. This command should NOT be used for type
81
<tt>b</tt>, <tt>m</tt> or <tt>r</tt> addresses.</dd>
83
<dt><tt>broadcast</tt></dt>
85
<dd>For type <tt>b</tt> and <tt>m</tt> addresses (only), this
86
command mobilizes a persistent broadcast mode association. Multiple
87
commands can be used to specify multiple local broadcast interfaces
88
(subnets) and/or multiple multicast groups. Note that local
89
broadcast messages go only to the interface associated with the
90
subnet specified, but multicast messages go to all interfaces.</dd>
92
<dd>In broadcast mode the local server sends periodic broadcast
93
messages to a client population at the <i><tt>address</tt></i>
94
specified, which is usually the broadcast address on (one of) the
95
local network(s) or a multicast address assigned to NTP. The IANA
96
has assigned the multicast group address 224.0.1.1 exclusively to
97
NTP, but other nonconflicting addresses can be used to contain the
98
messages within administrative boundaries. Ordinarily, this
99
specification applies only to the local server operating as a
100
sender; for operation as a broadcast client, see the <tt>
101
broadcastclient</tt> or <tt>multicastclient</tt> commands
104
<dt><tt>manycastclient</tt></dt>
106
<dd>For type <tt>m</tt> addresses (only), this command mobilizes a
107
manycast client mode association for the multicast address
108
specified. In this case a specific address must be supplied which
109
matches the address used on the <tt>manycastserver</tt> command for
110
the designated manycast servers. The NTP multicast address
111
224.0.1.1 assigned by the IANA should NOT be used, unless specific
112
means are taken to avoid spraying large areas of the Internet with
113
these messages and causing a possibly massive implosion of replies
116
<dd>The <tt>manycast</tt> command specifies that the local server
117
is to operate in client mode with the remote servers that are
118
discovered as the result of broadcast/multicast messages. The
119
client broadcasts a request message to the group address associated
120
with the specified <i><tt>address</tt></i> and specifically enabled
121
servers respond to these messages. The client selects the servers
122
providing the best time and continues as with the <tt>server</tt>
123
command. The remaining servers are discarded as if never
128
<dt><tt>autokey</tt></dt>
130
<dd>All packets sent to and received from the server or peer are to
131
include authentication fields encrypted using the autokey scheme
132
described in the <a href="authopt.htm">Authentication Options</a>
135
<dt><tt>burst</tt></dt>
137
<dd>when the server is reachable and at each poll interval, send a
138
burst of eight packets instead of the usual one packet. The spacing
139
between the first and the second packets is about 16s to allow a
140
modem call to complete, while the spacing between the remaining
141
packets is about 2s. This is designed to improve timekeeping
142
quality with the <tt>server</tt> command and <tt>s</tt>
145
<dt><tt>iburst</tt></dt>
147
<dd>When the server is unreachable and at each poll interval, send
148
a burst of eight packets instead of the usual one. As long as the
149
server is unreachable, the spacing between packets is about 16s to
150
allow a modem call to complete. Once the server is reachable, the
151
spacing between packets is about 2s. This is designed to speed the
152
initial synchronization acquisition with the <tt>server</tt>
153
command and <tt>s</tt> addresses and when <tt>ntpd</tt> is started
154
with the <tt>-q</tt> option.</dd>
156
<dt><tt>key</tt> <i><tt>key</tt></i></dt>
158
<dd>All packets sent to and received from the server or peer are to
159
include authentication fields encrypted using the specified <i>
160
key</i> identifier with values from 1 to 65534, inclusive. The
161
default is to include no encryption field.</dd>
163
<dt><tt>minpoll <i>minpoll</i></tt><br>
164
<tt>maxpoll <i>maxpoll</i></tt></dt>
166
<dd>These options specify the minimum and maximum poll intervals
167
for NTP messages, in seconds to the power of two. The maximum poll
168
interval defaults to 10 (1,024 s), but can be increased by the <tt>
169
maxpoll</tt> option to an upper limit of 17 (36.4 h). The minimum
170
poll interval defaults to 6 (64 s), but can be decreased by the
171
<tt>minpoll</tt> option to a lower limit of 4 (16 s).</dd>
173
<dt><tt>prefer</tt></dt>
175
<dd>Marks the server as preferred. All other things being equal,
176
this host will be chosen for synchronization among a set of
177
correctly operating hosts. See the <a href="prefer.htm">Mitigation
178
Rules and the <tt>prefer</tt> Keyword</a> page for further
181
<dt><tt>ttl <i>ttl</i></tt></dt>
183
<dd>This option is used only with broadcast server and manycast
184
client modes. It specifies the time-to-live <i><tt>ttl</tt></i> to
185
use on broadcast server and multicast server and the maximum <i>
186
<tt>ttl</tt></i> for the expanding ring search with manycast client
187
packets. Selection of the proper value, which defaults to 127, is
188
something of a black art and should be coordinated with the network
191
<dt><tt>version <i>version</i></tt></dt>
193
<dd>Specifies the version number to be used for outgoing NTP
194
packets. Versions 1-4 are the choices, with version 4 the
200
<h4>Auxilliary Commands</h4>
203
<dt><tt>broadcastclient</tt></dt>
205
<dd>This command enables reception of broadcast server messages to
206
any local interface (type b) address. Upon receiving a message for
207
the first time, the broadcast client measures the nominal server
208
propagation delay using a brief client/server exchange with the
209
server, then enters the broadcast client mode, in which it
210
synchronizes to succeeding broadcast messages. Note that, in order
211
to avoid accidental or malicious disruption in this mode, both the
212
server and client should operate using symmetric-key or public-key
213
authentication as described in the <a href="authopt.htm">
214
Authentication Options</a> page.</dd>
216
<dt><tt>manycastserver <i>address</i> [...]</tt></dt>
218
<dd>This command enables reception of manycast client messages to
219
the multicast group address(es) (type m) specified. At least one
220
address is required, but The NTP multicast address 224.0.1.1
221
assigned by the IANA should NOT be used, unless specific means are
222
taken to limit the span of the reply and avoid a possibly massive
223
implosion at the original sender. Note that, in order to avoid
224
accidental or malicious disruption in this mode, both the server
225
and client should operate using symmetric-key or public-key
226
authentication as described in the <a href="authopt.htm">
227
Authentication Options</a> page.</dd>
229
<dt><tt>multicastclient [<i>address</i>] [...]</tt></dt>
231
<dd>This command enables reception of multicast server messages to
232
the multicast group address(es) (type m) specified. Upon receiving
233
a message for the first time, the multicast client measures the
234
nominal server propagation delay using a brief client/server
235
exchange with the server, then enters the broadcast client mode, in
236
which it synchronizes to succeeding multicast messages. Note that,
237
in order to avoid accidental or malicious disruption in this mode,
238
both the server and client should operate using symmetric-key or
239
public-key authentication as described in the <a href=
240
"authopt.htm">Authentication Options</a> page.</dd>
245
<p>The syntax checking is not picky; some combinations of
246
ridiculous and even hilarious options and modes may not be
250
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
253
<address><a href="mailto:mills@udel.edu">David L. Mills
254
<mills@udel.edu></a></address>
added
removed
html/confopt.htm
