1ntp.conf(5) File Formats Manual ntp.conf(5)
2
6 ntp.conf - Server Options
7 Following is a description of the configuration commands in NTPv4.
10 There are two classes of commands, configuration commands that config‐
11 ure an association with a remote server, peer or reference clock, and
12 auxilliary commands that specify environmental variables that control
13 various related operations.
14
17 The various modes are determined by the command keyword and the
18 required IP address. Addresses are classed by type as (s) a remote
19 server or peer (IPv4 class A, B and C), (b) the broadcast address of a
20 local interface, (m) a multicast address (IPv4 class D), or (r) a ref‐
21 erence clock address (127.127.x.x). The options that can be used with
22 these commands are listed below.
23 If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is
25 detected, support for the IPv6 address family is generated in addition
26 to the default support of the IPv4 address family. IPv6 addresses can
27 be identified by the presence of colons ":" in the address field. IPv6
28 addresses can be used almost everywhere where IPv4 addresses can be
29 used, with the exception of reference clock addresses, which are always
30 IPv4. Note that in contexts where a host name is expected, a -4 quali‐
31 fier preceding the host name forces DNS resolution to the IPv4 names‐
32 pace, while a -6 qualifier forces DNS resolution to the IPv6 namespace.
33 There are three types of associations: persistent, preemptable and
35 ephemeral. Persistent associations are mobilized by a configuration
36 command and never demobilized. Preemptable associations, which are new
37 to NTPv4, are mobilized by a configuration command which includes the
38 prempt flag and are demobilized by timeout or error. Ephemeral associa‐
39 tions are mobilized upon arrival of designated messages and demobilized
40 by timeout or error.
41 server address [options ...]
44 peer address [options ...]
46 broadcast address [options ...]
48 manycastclient address [options ...]
50 These four commands specify the time server name or address to
51 be used and the mode in which to operate. The address can be
52 either a DNS name or a IP address in dotted-quad notation.
53 Additional information on association behavior can be found in
54 the Association Management page.
55 server For type s and r addresses (only), this command nor‐
57 mally mobilizes a persistent client mode association
58 with the specified remote server or local reference
59 clock. If the preempt flag is specified, a preemptable
60 association is mobilized instead. In client mode the
61 client clock can synchronize to the remote server or
62 local reference clock, but the remote server can never
63 be synchronized to the client clock. This command
64 should NOT be used for type b or m addresses.
65 peer For type s addresses (only), this command mobilizes a
67 persistent symmetric-active mode association with the
68 specified remote peer. In this mode the local clock can
69 be synchronized to the remote peer or the remote peer
70 can be synchronized to the local clock. This is useful
71 in a network of servers where, depending on various
72 failure scenarios, either the local or remote peer may
73 be the better source of time. This command should NOT
74 be used for type b, m or r addresses.
75 broadcast
77 For type b and m addresses (only), this command mobi‐
78 lizes a persistent broadcast mode association. Multiple
79 commands can be used to specify multiple local broad‐
80 cast interfaces (subnets) and/or multiple multicast
81 groups. Note that local broadcast messages go only to
82 the interface associated with the subnet specified, but
83 multicast messages go to all interfaces. In broadcast
84 mode the local server sends periodic broadcast messages
85 to a client population at the address specified, which
86 is usually the broadcast address on (one of) the local
87 network(s) or a multicast address assigned to NTP. The
88 IANA has assigned the multicast group address IPv4
89 224.0.1.1 and IPv6 ff05::101 (site local) exclusively
90 to NTP, but other nonconflicting addresses can be used
91 to contain the messages within administrative bound‐
92 aries. Ordinarily, this specification applies only to
93 the local server operating as a sender; for operation
94 as a broadcast client, see the broadcastclient or mul‐
95 ticastclient commands below.
96 manycastclient
98 For type m addresses (only), this command mobilizes a
99 preemptable manycast client mode association for the
100 multicast group address specified. In this mode a spe‐
101 cific address must be supplied which matches the
102 address used on the manycastserver command for the des‐
103 ignated manycast servers. The NTP multicast address
104 224.0.1.1 assigned by the IANA should NOT be used,
105 unless specific means are taken to avoid spraying large
106 areas of the Internet with these messages and causing a
107 possibly massive implosion of replies at the sender.
108 The manycastclient command specifies that the host is
109 to operate in client mode with the remote servers that
110 are discovered as the result of broadcast/multicast
111 messages. The client broadcasts a request message to
112 the group address associated with the specified address
113 and specifically enabled servers respond to these mes‐
114 sages. The client selects the servers providing the
115 best time and continues as with the server command. The
116 remaining servers are discarded as if never heard.
117
121 autokey All packets sent to and received from the server or peer are to
122 include authentication fields encrypted using the autokey
123 scheme described in the Authentication Options page. This
124 option is valid with all commands.
125 burst When the server is reachable, send a burst of eight packets
127 instead of the usual one. The packet spacing is normally 2 s;
128 however, the spacing between the first and second packets can
129 be changed with the calldelay command to allow additional time
130 for a modem or ISDN call to complete. This option is valid with
131 only the server command and is a recommended option with this
132 command when the maxpoll option is 11 or greater.
133 iburst When the server is unreachable, send a burst of eight packets
135 instead of the usual one. The packet spacing is normally 2 s;
136 however, the spacing between the first and second packets can
137 be changed with the calldelay command to allow additional time
138 for a modem or ISDN call to complete. This option is valid with
139 only the server command and is a recommended option with this
140 command.
141 key key All packets sent to and received from the server or peer are to
143 include authentication fields encrypted using the specified key
144 identifier with values from 1 to 65534, inclusive. The default
145 is to include no encryption field. This option is valid with
146 all commands.
147 minpoll minpoll
149 maxpoll maxpoll
151 These options specify the minimum and maximum poll intervals
152 for NTP messages, in seconds as a power of two. The maximum
153 poll interval defaults to 10 (1,024 s), but can be increased by
154 the maxpoll option to an upper limit of 17 (36.4 h). The mini‐
155 mum poll interval defaults to 6 (64 s), but can be decreased by
156 the minpoll option to a lower limit of 4 (16 s). These option
157 are valid only with the server and peer commands.
158 noselect
160 Marks the server as unused, except for display purposes. The
161 server is discarded by the selection algorithm. This option is
162 valid only with the server and peer commands.
163 preempt Specifies the association as preemptable rather than the
165 default persistent. This option is valied only with the server
166 command.
167 prefer Marks the server as preferred. All other things being equal,
169 this host will be chosen for synchronization among a set of
170 correctly operating hosts. See the Mitigation Rules and the
171 prefer Keyword page for further information. This option is
172 valid only with the server and peer commands.
173 true Force the association to assume truechimer status; that is,
175 always survive the selection and clustering algorithms. This
176 option can be used with any association, but is most useful for
177 reference clocks with large jitter on the serial port and pre‐
178 cision pulse-per-second (PPS) signals. Caution: this option
179 defeats the algorithms designed to cast out falsetickers and
180 can allow these sources to set the system clock. This option is
181 valid only with the server and peer commands.
182 ttl ttl This option is used only with broadcast server and manycast
184 client modes. It specifies the time-to-live ttl to use on
185 broadcast server and multicast server and the maximum ttl for
186 the expanding ring search with manycast client packets. Selec‐
187 tion of the proper value, which defaults to 127, is something
188 of a black art and should be coordinated with the network
189 administrator.
190 version version
192 Specifies the version number to be used for outgoing NTP pack‐
193 ets. Versions 1-4 are the choices, with version 4 the default.
194 This option is valid only with the server, peer and broadcast
195 commands.
196 dynamic Allows a server/peer to be configured even if it is not reach‐
198 able at configuration time. It is assumed that at some point in
199 the future the network environment changes so that this
200 server/peer can be reached. This option is useful to configure
201 servers/peers on mobile systems with intermittent network
202 access (e.g. wlan clients).
203
206 broadcastclient [novolley]
207 This command enables reception of broadcast server messages to
208 any local interface (type b) address. Ordinarily, upon receiv‐
209 ing a message for the first time, the broadcast client measures
210 the nominal server propagation delay using a brief
211 client/server exchange with the server, after which it contin‐
212 ues in listen-only mode. If the novolley keyword is present,
213 the exchange is not used and the value specified in the broad‐
214 castdelay command is used or, if the broadcastdelay command is
215 not used, the default 4.0 ms. Note that, in order to avoid
216 accidental or malicious disruption in this mode, both the
217 server and client should operate using symmetric key or public
218 key authentication as described in the Authentication Options
219 page. Note that the novolley keyword is incompatible with pub‐
220 lic key authentication.
221 manycastserver address [...]
223 This command enables reception of manycast client messages to
224 the multicast group address(es) (type m) specified. At least
225 one address is required. The NTP multicast address 224.0.1.1
226 assigned by the IANA should NOT be used, unless specific means
227 are taken to limit the span of the reply and avoid a possibly
228 massive implosion at the original sender. Note that, in order
229 to avoid accidental or malicious disruption in this mode, both
230 the server and client should operate using symmetric key or
231 public key authentication as described in the Authentication
232 Options page.
233 multicastclient address [...]
235 This command enables reception of multicast server messages to
236 the multicast group address(es) (type m) specified. Upon
237 receiving a message for the first time, the multicast client
238 measures the nominal server propagation delay using a brief
239 client/server exchange with the server, then enters the broad‐
240 cast client mode, in which it synchronizes to succeeding multi‐
241 cast messages. Note that, in order to avoid accidental or mali‐
242 cious disruption in this mode, both the server and client
243 should operate using symmetric key or public key authentication
244 as described in the Authentication Options page.
245
248 The syntax checking is not picky; some combinations of ridiculous and
249 even hilarious options and modes may not be detected.
250
253 ntpd(8), ntp_auth(5), ntp_mon(5), ntp_acc(5), ntp_clock(5), ntp_misc(5)
254 Primary source of documentation: /usr/share/doc/ntp-*
256 This file was automatically generated from HTML source.
258 ntp.conf(5)