9 .Nd Network Time Protocol (NTP) daemon configuration file
15 configuration file is read at initial startup by the
17 daemon in order to specify the synchronization sources,
18 modes and other related information.
19 Usually, it is installed in the
22 but could be installed elsewhere
29 script reads this file to get a list of NTP servers to use if the
35 man page for further info about this.
37 The file format is similar to other
42 character and extend to the end of the line;
43 blank lines are ignored.
44 Configuration commands consist of an initial keyword
45 followed by a list of arguments,
46 some of which may be optional, separated by whitespace.
47 Commands may not be continued over multiple lines.
48 Arguments may be host names,
49 host addresses written in numeric, dotted-quad form,
50 integers, floating point numbers (when specifying times in seconds)
53 The rest of this page describes the configuration and control options.
55 .Qq "Notes on Configuring NTP and Setting up a NTP Subnet"
57 (available as part of the HTML documentation
59 .Pa /usr/share/doc/ntp )
60 contains an extended discussion of these options.
61 In addition to the discussion of general
62 .Sx Configuration Options ,
63 there are sections describing the following supported functionality
64 and the options used to control it:
65 .Bl -bullet -offset indent
67 .Sx Authentication Support
69 .Sx Monitoring Support
71 .Sx Access Control Support
73 .Sx Reference Clock Support
76 Following these is a section describing
77 .Sx Miscellaneous Options .
78 While there is a rich set of options available,
79 the only required option is one or more
86 .Sh Configuration Support
87 Following is a description of the configuration commands in
89 These commands have the same basic functions as in NTPv3 and
90 in some cases new functions and new arguments.
92 classes of commands, configuration commands that configure a
93 persistent association with a remote server or peer or reference
94 clock, and auxiliary commands that specify environmental variables
95 that control various related operations.
96 .Ss Configuration Commands
97 The various modes are determined by the command keyword and the
98 type of the required IP address.
99 Addresses are classed by type as
100 (s) a remote server or peer (IP class A, B and C), (b) the
101 broadcast address of a local interface, (m) a multicast address (IP
102 class D), or (r) a reference clock address (127.127.x.x).
104 only those options applicable to each command are listed below.
106 of options not listed may not be caught as an error, but may result
107 in some weird and even destructive behavior.
108 .Bl -tag -width indent
109 .It Xo Ic server Ar address
110 .Op Cm key Ar key \&| Cm autokey
113 .Op Cm version Ar version
115 .Op Cm minpoll Ar minpoll
116 .Op Cm maxpoll Ar maxpoll
118 .It Xo Ic peer Ar address
119 .Op Cm key Ar key \&| Cm autokey
120 .Op Cm version Ar version
122 .Op Cm minpoll Ar minpoll
123 .Op Cm maxpoll Ar maxpoll
125 .It Xo Ic broadcast Ar address
126 .Op Cm key Ar key \&| Cm autokey
127 .Op Cm version Ar version
129 .Op Cm minpoll Ar minpoll
132 .It Xo Ic manycastclient Ar address
133 .Op Cm key Ar key \&| Cm autokey
134 .Op Cm version Ar version
136 .Op Cm minpoll Ar minpoll
137 .Op Cm maxpoll Ar maxpoll
142 These four commands specify the time server name or address to
143 be used and the mode in which to operate.
147 either a DNS name or an IP address in dotted-quad notation.
148 Additional information on association behavior can be found in the
149 .Qq "Association Management"
151 .Bl -tag -width indent
153 For type s and r addresses, this command mobilizes a persistent
154 client mode association with the specified remote server or local
156 In this mode the local clock can synchronized to the
157 remote server, but the remote server can never be synchronized to
164 For type s addresses (only), this command mobilizes a
165 persistent symmetric-active mode association with the specified
167 In this mode the local clock can be synchronized to
168 the remote peer or the remote peer can be synchronized to the local
170 This is useful in a network of servers where, depending on
171 various failure scenarios, either the local or remote peer may be
172 the better source of time.
173 This command should NOT be used for type
176 For type b and m addresses (only), this
177 command mobilizes a persistent broadcast mode association.
179 commands can be used to specify multiple local broadcast interfaces
180 (subnets) and/or multiple multicast groups.
182 broadcast messages go only to the interface associated with the
183 subnet specified, but multicast messages go to all interfaces.
184 In broadcast mode the local server sends periodic broadcast
185 messages to a client population at the
187 specified, which is usually the broadcast address on (one of) the
188 local network(s) or a multicast address assigned to NTP.
190 has assigned the multicast group address 224.0.1.1 exclusively to
191 NTP, but other nonconflicting addresses can be used to contain the
192 messages within administrative boundaries.
194 specification applies only to the local server operating as a
195 sender; for operation as a broadcast client, see the
201 .It Ic manycastclient
202 For type m addresses (only), this command mobilizes a
203 manycast client mode association for the multicast address
205 In this case a specific address must be supplied which
206 matches the address used on the
209 the designated manycast servers.
210 The NTP multicast address
211 224.0.1.1 assigned by the IANA should NOT be used, unless specific
212 means are taken to avoid spraying large areas of the Internet with
213 these messages and causing a possibly massive implosion of replies
217 command specifies that the local server
218 is to operate in client mode with the remote servers that are
219 discovered as the result of broadcast/multicast messages.
221 client broadcasts a request message to the group address associated
224 and specifically enabled
225 servers respond to these messages.
226 The client selects the servers
227 providing the best time and continues as with the
230 The remaining servers are discarded as if never
235 .Bl -tag -width indent
237 All packets sent to and received from the server or peer are to
238 include authentication fields encrypted using the autokey scheme
240 .Sx Authentication Options .
242 when the server is reachable and at each poll interval, send a
243 burst of eight packets instead of the usual one packet.
245 between the first and the second packets is about 16s to allow a
246 modem call to complete, while the spacing between the remaining
248 This is designed to improve timekeeping
254 When the server is unreachable and at each poll interval, send
255 a burst of eight packets instead of the usual one.
257 server is unreachable, the spacing between packets is about 16s to
258 allow a modem call to complete.
259 Once the server is reachable, the
260 spacing between packets is about 2s.
261 This is designed to speed the
262 initial synchronization acquisition with the
264 command and s addresses and when
271 All packets sent to and received from the server or peer are to
272 include authentication fields encrypted using the specified
274 identifier with values from 1 to 65534, inclusive.
276 default is to include no encryption field.
277 .It Cm minpoll Ar minpoll
278 .It Cm maxpoll Ar maxpoll
279 These options specify the minimum and maximum poll intervals
280 for NTP messages, in seconds to the power of two.
282 interval defaults to 10 (1,024 s), but can be increased by the
284 option to an upper limit of 17 (36.4 h).
286 minimum poll interval defaults to 6 (64 s), but can be decreased by
289 option to a lower limit of 4 (16 s).
291 Marks the server as preferred.
292 All other things being equal,
293 this host will be chosen for synchronization among a set of
294 correctly operating hosts.
296 .Qq "Mitigation Rules and the prefer Keyword"
300 This option is used only with broadcast server and manycast
302 It specifies the time-to-live
305 use on broadcast server and multicast server and the maximum
307 for the expanding ring search with manycast
309 Selection of the proper value, which defaults to
310 127, is something of a black art and should be coordinated with the
311 network administrator.
312 .It Cm version Ar version
313 Specifies the version number to be used for outgoing NTP
315 Versions 1-4 are the choices, with version 4 the
318 .Ss Auxiliary Commands
319 .Bl -tag -width indent
320 .It Ic broadcastclient
321 This command enables reception of broadcast server messages to
322 any local interface (type b) address.
323 Upon receiving a message for
324 the first time, the broadcast client measures the nominal server
325 propagation delay using a brief client/server exchange with the
326 server, then enters the broadcast client mode, in which it
327 synchronizes to succeeding broadcast messages.
329 to avoid accidental or malicious disruption in this mode, both the
330 server and client should operate using symmetric-key or public-key
331 authentication as described in
332 .Sx Authentication Options .
333 .It Ic manycastserver Ar address ...
334 This command enables reception of manycast client messages to
335 the multicast group address(es) (type m) specified.
337 address is required, but the NTP multicast address 224.0.1.1
338 assigned by the IANA should NOT be used, unless specific means are
339 taken to limit the span of the reply and avoid a possibly massive
340 implosion at the original sender.
341 Note that, in order to avoid
342 accidental or malicious disruption in this mode, both the server
343 and client should operate using symmetric-key or public-key
344 authentication as described in
345 .Sx Authentication Options .
346 .It Ic multicastclient Ar address ...
347 This command enables reception of multicast server messages to
348 the multicast group address(es) (type m) specified.
350 a message for the first time, the multicast client measures the
351 nominal server propagation delay using a brief client/server
352 exchange with the server, then enters the broadcast client mode, in
353 which it synchronizes to succeeding multicast messages.
355 in order to avoid accidental or malicious disruption in this mode,
356 both the server and client should operate using symmetric-key or
357 public-key authentication as described in
358 .Sx Authentication Options .
360 .Sh Authentication Support
361 Authentication support allows the NTP client to verify that the
362 server is in fact known and trusted and not an intruder intending
363 accidentally or on purpose to masquerade as that server.
365 specification RFC-1305 defines a scheme which provides
366 cryptographic authentication of received NTP packets.
368 this was done using the Data Encryption Standard (DES) algorithm
369 operating in Cipher Block Chaining (CBC) mode, commonly called
371 Subsequently, this was augmented by the RSA Message Digest
372 5 (MD5) algorithm using a private key, commonly called keyed-MD5.
373 Either algorithm computes a message digest, or one-way hash, which
374 can be used to verify the server has the correct private key and
377 NTPv4 retains the NTPv3 schemes, properly described as
378 symmetric-key cryptography and, in addition, provides a new Autokey
379 scheme based on public-key cryptography.
380 Public-key cryptography is
381 generally considered more secure than symmetric-key cryptography,
382 since the security is based on a private value which is generated
383 by each server and never revealed.
385 distribution and management functions involve only public values,
386 which considerably simplifies key distribution and storage.
388 Authentication is configured separately for each association
399 commands as described in
400 .Sx Configuration Options .
402 options described below specify the suite of keys, select the key
403 for each configured association and manage the configuration
408 flag controls whether new associations or
409 remote configuration commands require cryptographic authentication.
410 This flag can be set or reset by the
414 configuration commands and also by remote
415 configuration commands sent by a
419 If this flag is enabled, which is the default
420 case, new broadcast client and symmetric passive associations and
421 remote configuration commands must be cryptographically
422 authenticated using either symmetric-key or public-key schemes.
424 this flag is disabled, these operations are effective even if not
425 cryptographic authenticated.
426 It should be understood that operating
427 in the latter mode invites a significant vulnerability where a
428 rogue hacker can seriously disrupt client timekeeping.
430 In networks with firewalls and large numbers of broadcast
431 clients it may be acceptable to disable authentication, since that
432 avoids key distribution and simplifies network maintenance.
433 However, when the configuration file contains host names, or when a
434 server or client is configured remotely, host names are resolved
435 using the DNS and a separate name resolution process.
437 protect against bogus name server messages, name resolution
438 messages are authenticated using an internally generated key which
439 is normally invisible to the user.
440 However, if cryptographic
441 support is disabled, the name resolution process will fail.
443 can be avoided either by specifying IP addresses instead of host
444 names, which is generally inadvisable, or by enabling the flag for
445 name resolution and disabled it once the name resolution process is
448 An attractive alternative where multicast support is available
449 is manycast mode, in which clients periodically troll for servers.
450 Cryptographic authentication in this mode uses public-key schemes
452 The principle advantage of this manycast mode
453 is that potential servers need not be configured in advance, since
454 the client finds them during regular operation, and the
455 configuration files for all clients can be identical.
457 In addition to the default symmetric-key cryptographic support,
458 support for public-key cryptography is available if the requisite
460 software distribution has been installed before
461 building the distribution.
462 Public-key cryptography provides secure
463 authentication of servers without compromising accuracy and
465 The security model and protocol schemes for both
466 symmetric-key and public-key cryptography are described below.
467 .Ss Symmetric-Key Scheme
468 The original RFC-1305 specification allows any one of possibly
469 65,534 keys, each distinguished by a 32-bit key identifier, to
470 authenticate an association.
471 The servers and clients involved must
472 agree on the key and key identifier to authenticate their messages.
473 Keys and related information are specified in a key file, usually
476 which should be exchanged and stored
477 using secure procedures beyond the scope of the NTP protocol
479 Besides the keys used for ordinary NTP associations,
480 additional keys can be used as passwords for the
488 is first started, it reads the key file
491 command and installs the keys in the
493 However, the keys must be activated with the
496 This allows, for instance, the
497 installation of possibly several batches of keys and then
498 activating or deactivating each batch remotely using
500 This also provides a revocation capability that can
501 be used if a key becomes compromised.
504 command selects the key used as the password for the
508 command selects the key used
509 as the password for the
512 .Ss Public-Key Scheme
513 The original NTPv3 authentication scheme described in RFC-1305
514 continues to be supported; however, in NTPv4 an additional
515 authentication scheme called Autokey is available.
517 message digest, RSA public-key signature and Diffie-Hellman key
518 agreement algorithms available from several sources, but not
519 included in the NTPv4 software distribution.
523 package must be installed as
528 configure and build process automatically detects it and compiles
529 the routines required.
530 The Autokey scheme has several modes of
531 operation corresponding to the various NTP modes supported.
533 signatures with timestamps are used in all modes to verify the
534 source of cryptographic values.
535 All modes use a special cookie
536 which can be computed independently by the client and server.
538 symmetric modes the cookie is constructed using the Diffie-Hellman
539 key agreement algorithm.
540 In other modes the cookie is constructed
541 from the IP addresses and a private value known only to the server.
542 All modes use in addition a variant of the S-KEY scheme, in which a
543 pseudo-random key list is generated and used in reverse order.
544 These schemes are described along with an executive summary,
545 current status, briefing slides and reading list, in the
546 .Qq "Autonomous Authentication"
549 The cryptographic values used by the Autokey scheme are
550 incorporated as a set of files generated by the
552 program, including the
553 symmetric private keys, public/private key pair, and the agreement
557 page for a description of
558 the formats of these files.
559 They contain cryptographic values
560 generated by the algorithms of the
563 are in printable ASCII format.
564 All file names include the
565 timestamp, in NTP seconds, following the default names given below.
566 Since the file data are derived from random values seeded by the
567 system clock and the file name includes the timestamp, every
568 generation produces a different file and different file name.
572 file contains the DES/MD5 private keys.
574 must be distributed by secure means to other servers and clients
575 sharing the same security compartment and made visible only to
577 While this file is not used with the Autokey scheme, it is
578 needed to authenticate some remote configuration commands used by
586 contains the RSA private key.
587 It is useful only to the machine that
588 generated it and never shared with any other daemon or application
589 program, so must be made visible only to root.
593 file contains the agreement parameters,
594 which are used only in symmetric (active and passive) modes.
596 necessary that both peers beginning a symmetric-mode association
597 share the same parameters, but it does not matter which
600 If one of the peers contains
601 the parameters, the other peer obtains them using the Autokey
603 If both peers contain the parameters, the most recent
604 copy is used by both peers.
605 If a peer does not have the parameters,
606 they will be requested by all associations, either configured or
607 not; but, none of the associations can proceed until one of them
608 has received the parameters.
609 Once loaded, the parameters can be
610 provided on request to other clients and servers.
613 file can be also be distributed using insecure
614 means, since the data are public values.
617 .Pa ntpkey_ Ns Ar host
618 file contains the RSA public
621 is the name of the host.
624 .Pa ntpkey_ Ns Ar host
626 normally provided to other hosts using the Autokey protocol.
631 association requires the public
632 key associated with the particular server or peer to be loaded
633 either directly from a local file or indirectly from the server
634 using the Autokey protocol.
635 These files can be widely distributed
636 and stored using insecure means, since the data are public
640 .Pa ntpkey_certif_ Ns Ar host
642 the PKI certificate for the host.
643 This provides a binding between
644 the host hame and RSA public key.
645 In the current implementation the
646 certificate is obtained by a client, if present, but the contents
649 Due to the widespread use of interface-specific naming, the host
650 names used in configured and mobilized associations are determined
657 program and the Autokey protocol derive the
658 name of the public key file using the name returned by this
660 While every server and client is required to load their
661 own public and private keys, the public keys for each client or
662 peer association can be obtained from the server or peer using the
664 Note however, that at the current stage of
665 development the authenticity of the server or peer and the
666 cryptographic binding of the server name, address and public key is
667 not yet established by a certificate authority or web of trust.
668 .Ss Leapseconds Table
669 The NIST provides a table showing the epoch for all historic
670 occasions of leap second insertion since 1972.
672 shows each epoch of insertion along with the offset of
673 International Atomic Time (TAI) with respect to Coordinated
674 Universal Time (UTC), as disseminated by NTP.
676 obtained directly from NIST national time servers using
677 FTP as the ASCII file
678 .Pa pub/leap-seconds .
680 While not strictly a security function, the Autokey scheme
681 provides means to securely retrieve the leapsecond table from a
683 Servers load the leapsecond table directly from the
684 file specified in the
686 command, while clients can
687 load the table indirectly from the servers using the Autokey
689 Once loaded, the table can be provided on request to
690 other clients and servers.
692 All key files are installed by default in
694 which is normally in a shared file system
695 in NFS-mounted networks and avoids installing them in each machine
697 The default can be overridden by the
699 configuration command.
700 However, this is not a good place to install
701 the private key file, since each machine needs its own file.
703 suitable place to install it is in
706 not in a shared file system.
708 The recommended practice is to keep the timestamp extensions
709 when installing a file and to install a link from the default name
710 (without the timestamp extension) to the actual file.
712 new file generations to be activated simply by changing the link.
715 parses the link name when present to extract
716 the extension value and sends it along with the public key and host
718 This allows clients to verify that the file
719 and generation time are always current.
721 location of each file can be overridden by the
723 configuration command.
725 All cryptographic keys and related parameters should be
726 regenerated on a periodic and automatic basis, like once per month.
729 program uses the same timestamp extension
730 for all files generated at one time, so each generation is distinct
731 and can be readily recognized in monitoring data.
733 public/private key pair must be generated by every server and
734 client, the public keys and agreement parameters do not need to be
735 explicitly copied to all machines in the same security compartment,
736 since they can be obtained automatically using the Autokey
738 However, it is necessary that all primary servers have
739 the same agreement parameter file.
740 The recommended way to do this
741 is for one of the primary servers to generate that file and then
742 copy it to the other primary servers in the same compartment using
747 Future versions of the Autokey
748 protocol are to contain provisions for an agreement protocol to do
751 Servers and clients can make a new generation in the following
753 All machines have loaded the old generation at startup and are
755 At designated intervals, each machine generates
756 a new public/private key pair and makes links from the default file
757 names to the new file names.
761 and loads the new generation, with result clients no longer can
762 authenticate correctly.
763 The Autokey protocol is designed so that
764 after a few minutes the clients time out and restart the protocol
765 from the beginning, with result the new generation is loaded and
766 operation continues as before.
767 A similar procedure can be used for
768 the agreement parameter file, but in this case precautions must be
769 take to be sure that all machines with this file have the same
771 .Ss Authentication Commands
772 .Bl -tag -width indent
773 .It Ic autokey Op Ar logsec
774 Specifies the interval between regenerations of the session key
775 list used with the Autokey protocol.
776 Note that the size of the key
777 list for each association depends on this interval and the current
779 The default value is 12 (4096 s or about 1.1 hours).
780 For poll intervals above the specified interval, a session key list
781 with a single entry will be regenerated for every message
783 .It Ic controlkey Ar key
784 Specifies the key identifier to use with the
786 utility, which uses the standard
787 protocol defined in RFC-1305.
791 the key identifier for a trusted key, where the value can be in the
792 range 1 to 65534, inclusive.
794 .Op Cm flags Ar flags
795 .Op Cm privatekey Ar file
796 .Op Cm publickey Ar file
797 .Op Cm dhparms Ar file
800 This command requires the NTP daemon build process be
801 configured with the RSA library.
802 This command activates public-key
803 cryptography and loads the required RSA private and public key
804 files and the optional Diffie-Hellman agreement parameter file, if
806 If one or more files are left unspecified, the default
807 names are used as described below.
810 .Bl -tag -width indent
811 .It Cm privatekey Ar file
812 Specifies the location of the RSA private key file, which
813 otherwise defaults to
814 .Pa /usr/local/etc/ntpkey .
815 .It Cm publickey Ar file
816 Specifies the location of the RSA public key file, which
817 otherwise defaults to
818 .Pa /usr/local/etc/ntpkey_ Ns Ar host ,
821 is the name of the generating machine.
822 .It Cm dhparms Ar file
823 Specifies the location of the Diffie-Hellman parameters file,
824 which otherwise defaults to
825 .Pa /usr/local/etc/ntpkey_dh .
827 Specifies the location of the leapsecond table file, which
828 otherwise defaults to
829 .Pa /usr/local/etc/ntpkey_leap .
831 .It Ic keys Ar keyfile
832 Specifies the location of the DES/MD5 private key file
833 containing the keys and key identifiers used by
838 when operating in symmetric-key
840 .It Ic keysdir Ar path
841 This command requires the NTP daemon build process be
842 configured with the RSA library.
843 It specifies the default directory
844 path for the private key file, agreement parameters file and one or
845 more public key files.
846 The default when this command does not
847 appear in the configuration file is
849 .It Ic requestkey Ar key
850 Specifies the key identifier to use with the
852 utility program, which uses a
853 proprietary protocol specific to this implementation of
857 argument is a key identifier
858 for the trusted key, where the value can be in the range 1 to
860 .It Ic revoke Ar logsec
861 Specifies the interval between re-randomization of certain
862 cryptographic values used by the Autokey scheme, as a power of 2 in
864 These values need to be updated frequently in order to
865 deflect brute-force attacks on the algorithms of the scheme;
866 however, updating some values is a relatively expensive operation.
867 The default interval is 16 (65,536 s or about 18 hours).
869 intervals above the specified interval, the values will be updated
870 for every message sent.
871 .It Ic trustedkey Ar key ...
872 Specifies the key identifiers which are trusted for the
873 purposes of authenticating peers with symmetric-key cryptography,
874 as well as keys used by the
879 The authentication procedures require that both the local
880 and remote servers share the same key and key identifier for this
881 purpose, although different keys can be used with different
885 arguments are 32-bit unsigned
886 integers with values from 1 to 65,534.
888 .Sh Monitoring Support
890 includes a comprehensive monitoring facility suitable
891 for continuous, long term recording of server and client
892 timekeeping performance.
896 for a listing and example of each type of statistics currently
898 Statistic files are managed using file generation sets
901 directory of this distribution.
906 jobs, the data can be
907 automatically summarized and archived for retrospective analysis.
908 .Ss Monitoring Commands
909 .Bl -tag -width indent
910 .It Ic statistics Ar name ...
911 Enables writing of statistics records.
912 Currently, four kinds of
914 statistics are supported.
915 .Bl -tag -width indent
917 Enables recording of loop filter statistics information.
919 update of the local clock outputs a line of the following form to
920 the file generation set named loopstats:
922 50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6
925 The first two fields show the date (Modified Julian Day) and
926 time (seconds and fraction past UTC midnight).
928 show time offset (seconds), frequency offset (parts per million -
929 PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
930 discipline time constant.
932 Enables recording of peer statistics information.
934 statistics records of all peers of a NTP server and of special
935 signals, where present and configured.
936 Each valid update appends a
937 line of the following form to the current element of a file
938 generation set named peerstats:
940 48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142
943 The first two fields show the date (Modified Julian Day) and
944 time (seconds and fraction past UTC midnight).
946 show the peer address in dotted-quad notation and status,
948 The status field is encoded in hex in the format
949 described in Appendix A of the NTP specification RFC 1305.
951 final three fields show the offset, delay and RMS jitter, all in
954 Enables recording of clock driver statistics information.
956 update received from a clock driver appends a line of the following
957 form to the file generation set named clockstats:
959 49213 525.624 127.127.4.1 93 226 00:08:29.606 D
962 The first two fields show the date (Modified Julian Day) and
963 time (seconds and fraction past UTC midnight).
965 the clock address in dotted-quad notation.
966 The final field shows
967 the last timecode received from the clock in decoded ASCII format,
969 In some clock drivers a good deal of additional
970 information can be gathered and displayed as well.
972 specific to each clock for further details.
974 Enables recording of raw-timestamp statistics information.
976 includes statistics records of all peers of a NTP server and of
977 special signals, where present and configured.
979 received from a peer or clock driver appends a line of the
980 following form to the file generation set named rawstats:
982 50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
984 The first two fields show the date (Modified Julian Day) and
985 time (seconds and fraction past UTC midnight).
987 show the remote peer or clock address followed by the local address
988 in dotted-quad notation.
989 The final four fields show the originate,
990 receive, transmit and final NTP timestamps in order.
992 values are as received and before processing by the various data
993 smoothing and mitigation algorithms.
995 .It Ic statsdir Ar directory_path
996 Indicates the full path of a directory where statistics files
997 should be created (see below).
998 This keyword allows the (otherwise
1001 filename prefix to be modified for file
1002 generation sets, which is useful for handling statistics logs.
1003 .It Xo Ic filegen Ar name
1004 .Op Cm file Ar filename
1005 .Op Cm type Ar typename
1006 .Op Cm link \&| Cm nolink
1007 .Op Cm enable \&| Cm disable
1009 Configures setting of generation file set
1011 Generation file sets provide a means for handling files that are
1012 continuously growing during the lifetime of a server.
1014 statistics are a typical example for such files.
1016 sets provide access to a set of files used to store the actual
1018 At any time at most one element of the set is being written
1020 The type given specifies when and how data will be directed to
1021 a new element of the set.
1022 This way, information stored in elements
1023 of a file set that are currently unused are available for
1024 administrational operations without the risk of disturbing the
1027 (Most important: they can be removed to
1028 free space for new data produced.)
1029 Note that this command can be sent from the
1031 program running at a remote location.
1032 .Bl -tag -width indent
1034 This is the type of the statistics records, as shown in the
1037 .It Cm file Ar filename
1038 This is the file name for the statistics records.
1040 set members are built from three concatenated elements
1041 prefix, filename and
1043 .Bl -tag -width indent
1045 This is a constant filename path.
1046 It is not subject to
1047 modifications via the
1050 It is defined by the
1051 server, usually specified as a compile-time constant.
1053 however, be configurable for individual file generation sets via
1055 For example, the prefix used with
1060 configured using the
1062 option explained above.
1064 This string is directly concatenated to the prefix mentioned
1065 above (no intervening
1068 This can be modified
1076 elements are allowed in this component to prevent
1077 filenames referring to parts outside the file system hierarchy
1080 This part is reflects individual elements of a file set.
1082 generated according to the type of a file set.
1084 .It Cm type Ar typename
1085 A file generation set is characterized by its type.
1087 following types are supported:
1088 .Bl -tag -width indent
1090 The file set is actually a single plain file.
1092 One element of file set is used per incarnation of a
1095 This type does not perform any changes to
1096 file set members during runtime, however it provides an easy way of
1097 separating files belonging to different
1101 The set member filename is built by appending a
1103 (dot) to concatenated prefix and filename
1104 strings, and appending the decimal representation of the process ID
1109 One file generation set element is created per day.
1111 defined as the period between 00:00 and 24:00 UTC.
1113 member suffix consists of a
1116 specification in the form
1120 number (e.g., 1992).
1122 is a two digit month number.
1124 is a two digit day number.
1125 Thus, all information
1126 written at 10 December 1992 would end up in a file named
1128 .Pa Ar prefix / Ar filename / 19921210 .
1131 Any file set member contains data related to a certain week of
1133 The term week is defined by computing day-of-year modulo 7.
1134 Elements of such a file generation set are distinguished by
1135 appending the following suffix to the file set filename base: A
1136 dot, a 4-digit year number, the letter
1140 For example, information from January, 10th 1992 would
1141 end up in a file with suffix
1144 One generation file set element is generated per month.
1146 file name suffix consists of a dot, a 4-digit year number, and a
1149 One generation file element is generated per year.
1151 suffix consists of a dot and a 4 digit year number.
1153 This type of file generation sets changes to a new element of
1154 the file set every 24 hours of server operation.
1156 suffix consists of a dot, the letter
1160 This number is taken to be the number of seconds the server
1161 is running at the start of the corresponding 24-hour period.
1162 Information is only written to a file generation by specifying
1164 output is prevented by specifying
1167 .It Cm link \&| Cm nolink
1168 It is convenient to be able to access the current element of a
1169 file generation set by a fixed name.
1170 This feature is enabled by
1177 is specified, a hard link from the current file set
1178 element to a file without suffix is created.
1179 When there is already
1180 a file with this name and the number of links of this file is one,
1181 it is renamed appending a dot, the letter
1187 When the number of links is
1188 greater than one, the file is unlinked.
1189 This allows the current
1190 file to be accessed by a constant name.
1191 .It Cm enable \&| Cm disable
1192 Enables or disables the recording function.
1195 .Sh Access Control Support
1197 implements a general purpose address-and-mask based
1199 The list is sorted by address and by mask, and
1200 the list is searched in this order for matches, with the last match
1201 found defining the restriction flags associated with the incoming
1203 The source address of incoming packets is used for the
1204 match, with the 32- bit address being and'ed with the mask
1205 associated with the restriction entry and then compared with the
1206 entry's address (which has also been and'ed with the mask) to look
1208 Additional information and examples can be found in the
1209 .Qq "Notes on Configuring NTP and Setting up a NTP Subnet"
1212 The restriction facility was implemented in conformance with the
1213 access policies for the original NSFnet backbone time servers.
1214 While this facility may be otherwise useful for keeping unwanted or
1215 broken remote time servers from affecting your own, it should not
1216 be considered an alternative to the standard NTP authentication
1218 Source address based restrictions are easily circumvented
1219 by a determined cracker.
1220 .Ss The Kiss-of-Death Packet
1221 Ordinarily, packets denied service are simply dropped with no
1222 further action except incrementing statistics counters.
1224 more proactive response is needed, such as a server message that
1225 explicitly requests the client to stop sending and leave a message
1226 for the system operator.
1227 A special packet format has been created
1228 for this purpose called the kiss-of-death packet.
1231 flag is set and either service is denied or the client
1232 limit is exceeded, the server returns the packet and sets the
1233 leap bits unsynchronized, stratum zero and the ASCII string "DENY"
1234 in the reference source identifier field.
1238 is not set, the server simply drops the packet.
1240 A client or peer receiving a kiss-of-death packet performs a set
1241 of sanity checks to minimize security exposure.
1243 first packet received from the server, the client assumes an access
1244 denied condition at the server.
1245 It updates the stratum and
1246 reference identifier peer variables and sets the access denied
1247 (test 4) bit in the peer flash variable.
1248 If this bit is set, the
1249 client sends no packets to the server.
1250 If this is not the first
1251 packet, the client assumes a client limit condition at the server,
1252 but does not update the peer variables.
1253 In either case, a message
1254 is sent to the system log.
1255 .Ss Access Control Commands
1256 .Bl -tag -width indent
1257 .It Xo Ic restrict numeric_address
1258 .Op Cm mask Ar numeric_mask
1263 argument, expressed in
1264 dotted-quad form, is the address of a host or network.
1267 also expressed in dotted-quad form,
1268 defaults to 255.255.255.255, meaning that the
1270 is treated as the address of an
1272 A default entry (address 0.0.0.0, mask
1273 0.0.0.0) is always included and, given the sort algorithm,
1274 is always the first entry in the list.
1277 is normally given in dotted-quad
1278 format, the text string
1280 with no mask option, may
1281 be used to indicate the default entry.
1282 In the current implementation,
1285 restricts access, i.e., an entry with no flags indicates that free
1286 access to the server is to be given.
1287 The flags are not orthogonal,
1288 in that more restrictive flags will often make less restrictive
1290 The flags can generally be classed into two
1291 categories, those which restrict time service and those which
1292 restrict informational queries and attempts to do run-time
1293 reconfiguration of the server.
1294 One or more of the following flags
1296 .Bl -tag -width indent
1298 If access is denied, send a kiss-of-death packet.
1300 Ignore all packets from hosts which match this entry.
1302 flag is specified neither queries nor time server polls will be
1305 Ignore all NTP mode 6 and 7 packets (i.e., information queries
1306 and configuration requests) from the source.
1310 Ignore all NTP mode 6 and 7 packets which attempt to modify the
1311 state of the server (i.e., run time reconfiguration).
1313 return information are permitted.
1315 Decline to provide mode 6 control message trap service to
1317 The trap service is a subsystem of the mode 6
1318 control message protocol which is intended for use by remote event
1321 Declare traps set by matching hosts to be low priority.
1323 number of traps a server can maintain is limited (the current limit
1325 Traps are usually assigned on a first come, first served
1326 basis, with later trap requestors being denied service.
1328 modifies the assignment algorithm by allowing low priority traps to
1329 be overridden by later requests for normal priority traps.
1331 Ignore NTP packets whose mode is other than 6 or 7.
1333 time service is denied, though queries may still be permitted.
1335 Provide stateless time service to polling hosts, but do not
1336 allocate peer memory resources to these hosts even if they
1337 otherwise might be considered useful as future synchronization
1340 Treat these hosts normally in other respects, but never use
1341 them as synchronization sources.
1343 These hosts are subject to limitation of number of clients from
1345 Net in this context refers to the IP notion of net
1346 (class A, class B, class C, etc.).
1349 hosts that have shown up at the server and
1350 that have been active during the last
1351 .Va client_limit_period
1352 seconds are accepted.
1353 Requests from other clients from the same net
1355 Only time request packets are taken into account.
1356 Query packets sent by the
1361 are not subject to these limits.
1362 A history of clients is kept using
1363 the monitoring capability of
1366 always active as long as there is a restriction entry with the
1370 This is actually a match algorithm modifier, rather than a
1372 Its presence causes the restriction entry to be
1373 matched only if the source port in the packet is the standard NTP
1383 is considered more specific and
1384 is sorted later in the list.
1386 Ignore these hosts if not the current NTP version.
1389 Default restriction list entries, with the flags
1393 for each of the local host's interface
1394 addresses are inserted into the table at startup to prevent the
1395 server from attempting to synchronize to its own time.
1397 entry is also always present, though if it is otherwise
1398 unconfigured; no flags are associated with the default entry (i.e.,
1399 everything besides your own NTP server is unrestricted).
1400 .It Ic clientlimit Ar limit
1403 variable, which limits the number
1404 of simultaneous access-controlled clients.
1405 The default value for
1407 .It Ic clientperiod Ar period
1409 .Va client_limit_period
1410 variable, which specifies
1411 the number of seconds after which a client is considered inactive
1412 and thus no longer is counted for client limit restriction.
1414 default value for this variable is 3600 seconds.
1416 .Sh Reference Clock Support
1417 The NTP Version 4 daemon supports some three dozen different radio,
1418 satellite and modem reference clocks plus a special pseudo-clock
1419 used for backup or when no other clock source is available.
1420 Detailed descriptions of individual device drivers and options can
1422 .Qq "Reference Clock Drivers"
1424 (available as part of the HTML documentation
1426 .Pa /usr/share/doc/ntp ) .
1427 Additional information can be found in the pages linked
1428 there, including the
1429 .Qq "Debugging Hints for Reference Clock Drivers"
1431 .Qq "How To Write a Reference Clock Driver"
1433 In addition, support for a PPS
1434 signal is available as described in the
1435 .Qq "Pulse-per-second (PPS) Signal Interfacing"
1438 drivers support special line discipline/streams modules which can
1439 significantly improve the accuracy using the driver.
1442 .Qq "Line Disciplines and Streams Drivers"
1445 A reference clock will generally (though not always) be a radio
1446 timecode receiver which is synchronized to a source of standard
1447 time such as the services offered by the NRC in Canada and NIST and
1449 The interface between the computer and the timecode
1450 receiver is device dependent, but is usually a serial port.
1452 device driver specific to each reference clock must be selected and
1453 compiled in the distribution; however, most common radio, satellite
1454 and modem clocks are included by default.
1455 Note that an attempt to
1456 configure a reference clock when the driver has not been compiled
1457 or the hardware port has not been appropriately configured results
1458 in a scalding remark to the system log file, but is otherwise non
1461 For the purposes of configuration,
1464 reference clocks in a manner analogous to normal NTP peers as much
1466 Reference clocks are identified by a syntactically
1467 correct but invalid IP address, in order to distinguish them from
1469 Reference clock addresses are of the form
1471 .Li 127.127. Ar t . Ar u ,
1476 denoting the clock type and
1479 number in the range 0-3.
1480 While it may seem overkill, it is in fact
1481 sometimes useful to configure multiple reference clocks of the same
1482 type, in which case the unit numbers must be unique.
1486 command is used to configure a reference
1489 argument in that command
1490 is the clock address.
1496 options are not used for reference clock support.
1499 option is added for reference clock support, as
1503 option can be useful to
1504 persuade the server to cherish a reference clock with somewhat more
1505 enthusiasm than other reference clocks or peers.
1507 information on this option can be found in the
1508 .Qq "Mitigation Rules and the prefer Keyword"
1515 meaning only for selected clock drivers.
1516 See the individual clock
1517 driver document pages for additional information.
1521 command is used to provide additional
1522 information for individual clock drivers and normally follows
1523 immediately after the
1528 argument specifies the clock address.
1533 options can be used to
1534 override the defaults for the device.
1535 There are two optional
1536 device-dependent time offsets and four flags that can be included
1541 The stratum number of a reference clock is by default zero.
1544 daemon adds one to the stratum of each
1545 peer, a primary server ordinarily displays an external stratum of
1547 In order to provide engineered backups, it is often useful to
1548 specify the reference clock stratum as greater than zero.
1551 option is used for this purpose.
1553 involving both a reference clock and a pulse-per-second (PPS)
1554 discipline signal, it is useful to specify the reference clock
1555 identifier as other than the default, depending on the driver.
1558 option is used for this purpose.
1560 these options apply to all clock drivers.
1561 .Ss Reference Clock Commands
1562 .Bl -tag -width indent
1565 .Li 127.127. Ar t . Ar u
1569 .Op Cm minpoll Ar int
1570 .Op Cm maxpoll Ar int
1572 This command can be used to configure reference clocks in
1574 The options are interpreted as follows:
1575 .Bl -tag -width indent
1577 Marks the reference clock as preferred.
1578 All other things being
1579 equal, this host will be chosen for synchronization among a set of
1580 correctly operating hosts.
1582 .Qq "Mitigation Rules and the prefer Keyword"
1586 Specifies a mode number which is interpreted in a
1587 device-specific fashion.
1588 For instance, it selects a dialing
1589 protocol in the ACTS driver and a device subtype in the
1592 .It Cm minpoll Ar int
1593 .It Cm maxpoll Ar int
1594 These options specify the minimum and maximum polling interval
1595 for reference clock messages, in seconds to the power of two.
1597 most directly connected reference clocks, both
1601 default to 6 (64 s).
1602 For modem reference clocks,
1604 defaults to 10 (17.1 m) and
1606 defaults to 14 (4.5 h).
1607 The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
1611 .Li 127.127. Ar t . Ar u
1615 .Op Cm stratum Ar int
1616 .Op Cm refid Ar string
1618 .Op Cm flag1 Cm 0 \&| Cm 1
1619 .Op Cm flag2 Cm 0 \&| Cm 1
1620 .Op Cm flag3 Cm 0 \&| Cm 1
1621 .Op Cm flag4 Cm 0 \&| Cm 1
1623 This command can be used to configure reference clocks in
1625 It must immediately follow the
1627 command which configures the driver.
1628 Note that the same capability
1629 is possible at run time using the
1632 The options are interpreted as
1634 .Bl -tag -width indent
1636 Specifies a constant to be added to the time offset produced by
1637 the driver, a fixed-point decimal number in seconds.
1639 as a calibration constant to adjust the nominal time offset of a
1640 particular clock to agree with an external standard, such as a
1641 precision PPS signal.
1642 It also provides a way to correct a
1643 systematic error or bias due to serial port or operating system
1644 latencies, different cable lengths or receiver internal delay.
1646 specified offset is in addition to the propagation delay provided
1647 by other means, such as internal DIPswitches.
1649 for an individual system and driver is available, an approximate
1650 correction is noted in the driver documentation pages.
1651 Note: in order to facilitate calibration when more than one
1652 radio clock or PPS signal is supported, a special calibration
1653 feature is available.
1654 It takes the form of an argument to the
1656 command described in
1657 .Sx Miscellaneous Options
1658 page and operates as described in the
1659 .Qq "Reference Clock Drivers"
1661 .It Cm time2 Ar secs
1662 Specifies a fixed-point decimal number in seconds, which is
1663 interpreted in a driver-dependent way.
1664 See the descriptions of
1665 specific drivers in the
1666 .Qq "reference clock drivers"
1668 .It Cm stratum Ar int
1669 Specifies the stratum number assigned to the driver, an integer
1671 This number overrides the default stratum number
1672 ordinarily assigned by the driver itself, usually zero.
1673 .It Cm refid Ar string
1674 Specifies an ASCII string of from one to four characters which
1675 defines the reference identifier used by the driver.
1677 overrides the default identifier ordinarily assigned by the driver
1680 Specifies a mode number which is interpreted in a
1681 device-specific fashion.
1682 For instance, it selects a dialing
1683 protocol in the ACTS driver and a device subtype in the
1686 .It Cm flag1 Cm 0 \&| Cm 1
1687 .It Cm flag2 Cm 0 \&| Cm 1
1688 .It Cm flag3 Cm 0 \&| Cm 1
1689 .It Cm flag4 Cm 0 \&| Cm 1
1690 These four flags are used for customizing the clock driver.
1692 interpretation of these values, and whether they are used at all,
1693 is a function of the particular clock driver.
1697 is used to enable recording monitoring
1700 file configured with the
1703 Further information on the
1705 command can be found in
1706 .Sx Monitoring Options .
1709 .Sh Miscellaneous Options
1710 .Bl -tag -width indent
1711 .It Ic broadcastdelay Ar seconds
1712 The broadcast and multicast modes require a special calibration
1713 to determine the network delay between the local and remote
1715 Ordinarily, this is done automatically by the initial
1716 protocol exchanges between the client and server.
1718 the calibration procedure may fail due to network or server access
1719 controls, for example.
1720 This command specifies the default delay to
1721 be used under these circumstances.
1722 Typically (for Ethernet), a
1723 number between 0.003 and 0.007 seconds is appropriate.
1725 when this command is not used is 0.004 seconds.
1726 .It Ic driftfile Ar driftfile
1727 This command specifies the name of the file used to record the
1728 frequency offset of the local clock oscillator.
1730 it is read at startup in order to set the initial frequency offset
1731 and then updated once per hour with the current frequency offset
1732 computed by the daemon.
1733 If the file does not exist or this command
1734 is not given, the initial frequency offset is assumed zero.
1736 case, it may take some hours for the frequency to stabilize and the
1737 residual timing errors to subside.
1739 The file format consists of a single line containing a single
1740 floating point number, which records the frequency offset measured
1741 in parts-per-million (PPM).
1742 The file is updated by first writing
1743 the current drift value into a temporary file and then renaming
1744 this file to replace the old version.
1747 must have write permission for the directory the
1748 drift file is located in, and that file system links, symbolic or
1749 otherwise, should be avoided.
1752 .Cm auth | Cm bclient |
1753 .Cm calibrate | Cm kernel |
1754 .Cm monitor | Cm ntp |
1760 .Cm auth | Cm bclient |
1761 .Cm calibrate | Cm kernel |
1762 .Cm monitor | Cm ntp |
1766 Provides a way to enable or disable various server options.
1767 Flags not mentioned are unaffected.
1768 Note that all of these flags
1769 can be controlled remotely using the
1772 .Bl -tag -width indent
1774 When enabled, this is identical to the
1777 The default for this flag is
1780 Enables the calibration facility, which automatically adjusts
1783 values for each clock driver to display the same
1784 offset as the currently selected source or kernel discipline
1787 .Qq "Reference Clock Drivers"
1789 for further information.
1790 The default for this flag is
1793 Enables the precision-time kernel support for the
1795 system call, if implemented.
1797 support for this routine is detected automatically when the NTP
1798 daemon is compiled, so it is not necessary for the user to worry
1800 It is provided primarily so that this support
1801 can be disabled during kernel development.
1802 The default for this
1806 Enables the monitoring facility.
1812 command or further information.
1814 default for this flag is
1817 Enables the server to adjust its local clock by means of NTP.
1818 If disabled, the local clock free-runs at its intrinsic time and
1820 This flag is useful in case the local clock is
1821 controlled by some other device or protocol and NTP is used only to
1822 provide synchronization to other clients.
1823 In this case, the local
1824 clock driver can be used to provide this function and also certain
1825 time variables for error estimates and leap-indicators.
1827 .Qq "Reference Clock Drivers"
1830 The default for this flag is
1833 Enables the statistics facility.
1835 .Qq "Monitoring Options"
1836 page for further information.
1837 The default for this flag is
1840 .It Ic logconfig Ar configkeyword
1841 This command controls the amount and type of output written to
1844 facility or the alternate
1847 By default, all output is turned on.
1850 keywords can be prefixed with
1866 messages can be controlled in four
1875 Within these classes four types of messages can be
1877 Informational messages
1879 control configuration
1884 events (reachability, synchronization, alarm conditions).
1885 Statistical output is controlled with the
1888 The final message group is the status messages.
1890 describes mainly the synchronizations status.
1892 keywords are formed by concatenating the message class with the
1896 prefix can be used instead of a
1898 A message class may also be followed by the
1900 keyword to enable/disable all messages of the
1901 respective message class.
1902 Thus, a minimal log configuration could look like this:
1904 logconfig =syncstatus +sysevents
1907 This would just list the synchronizations state of
1909 and the major system events.
1910 For a simple reference server, the
1911 following minimum message configuration could be useful:
1913 logconfig =syncall +clockall
1916 This configuration will list all clock information and
1917 synchronization information.
1918 All other events and messages about
1919 peers, system events and so on is suppressed.
1920 .It Ic logfile Ar logfile
1921 This command specifies the location of an alternate log file to
1922 be used instead of the default system
1925 .It Ic setvar Ar variable Op Cm default
1926 This command adds an additional system variable.
1928 variables can be used to distribute additional information such as
1930 If the variable of the form
1937 variable will be listed as part of the default system variables
1943 These additional variables serve
1944 informational purposes only.
1945 They are not related to the protocol
1946 other that they can be listed.
1947 The known protocol variables will
1948 always override any variables defined via the
1951 There are three special variables that contain the names
1952 of all variable of the same group.
1956 the names of all system variables.
1960 the names of all peer variables and the
1962 holds the names of the reference clock variables.
1966 .Cm panic Ar panic |
1967 .Cm dispersion Ar dispersion |
1968 .Cm stepout Ar stepout |
1969 .Cm minpoll Ar minpoll |
1970 .Cm allan Ar allan |
1971 .Cm huffpuff Ar huffpuff
1974 This command can be used to alter several system variables in
1975 very exceptional circumstances.
1976 It should occur in the
1977 configuration file before any other configuration options.
1979 default values of these variables have been carefully optimized for
1980 a wide range of network speeds and reliability expectations.
1982 general, they interact in intricate ways that are hard to predict
1983 and some combinations can result in some very nasty behavior.
1985 rarely is it necessary to change the default values; but, some
1986 folks cannot resist twisting the knobs anyway and this command is
1988 Emphasis added: twisters are on their own and can expect
1989 no help from the support group.
1991 All arguments are in floating point seconds or seconds per
1995 argument is an integer in seconds to
1997 The variables operate as follows:
1998 .Bl -tag -width indent
2000 The argument becomes the new value for the step threshold,
2002 If set to zero, step adjustments will never
2004 In general, if the intent is only to avoid step adjustments,
2005 the step threshold should be left alone and the
2008 line option be used instead.
2009 .It Cm panic Ar panic
2010 The argument becomes the new value for the panic threshold,
2012 If set to zero, the panic sanity check is disabled
2013 and a clock offset of any value will be accepted.
2014 .It Cm dispersion Ar dispersion
2015 The argument becomes the new value for the dispersion increase
2016 rate, normally .000015.
2017 .It Cm stepout Ar stepout
2018 The argument becomes the new value for the watchdog timeout,
2020 .It Cm minpoll Ar minpoll
2021 The argument becomes the new value for the minimum poll
2022 interval used when configuring multicast client, manycast client
2023 and , symmetric passive mode association.
2024 The value defaults to 6
2025 (64 s) and has a lower limit of 4 (16 s).
2026 .It Cm allan Ar allan
2027 The argument becomes the new value for the minimum Allan
2028 intercept, which is a parameter of the PLL/FLL clock discipline
2030 The value defaults to 1024 s, which is also the lower
2032 .It Cm huffpuff Ar huffpuff
2033 The argument becomes the new value for the experimental
2034 huff-n'-puff filter span, which determines the most recent interval
2035 the algorithm will search for a minimum delay.
2037 900 s (15 m), but a more reasonable value is 7200 (2 hours).
2039 is no default, since the filter is not enabled unless this command
2042 .It Xo Ic trap Ar host_address
2043 .Op Cm port Ar port_number
2044 .Op Cm interface Ar interface_address
2046 This command configures a trap receiver at the given host
2047 address and port number for sending messages with the specified
2048 local interface address.
2049 If the port number is unspecified, a value
2051 If the interface address is not specified, the
2052 message is sent with a source address of the local interface the
2053 message is sent through.
2054 Note that on a multihomed host the
2055 interface used may vary from time to time with routing changes.
2057 The trap receiver will generally log event messages and other
2058 information from the server in a log file.
2060 programs may also request their own trap dynamically, configuring a
2061 trap receiver will ensure that no messages are lost when the server
2065 .Bl -tag -width /etc/ntp.drift -compact
2066 .It Pa /etc/ntp.conf
2067 the default name of the configuration file
2072 .It Pa ntpkey_ Ns Ar host
2075 Diffie-Hellman agreement parameters
2083 In addition to the manual pages provided,
2084 comprehensive documentation is available on the world wide web
2086 .Li http://www.ntp.org/ .
2087 A snapshot of this documentation is available in HTML format in
2088 .Pa /usr/share/doc/ntp .
2091 .%T Network Time Protocol (Version 3)
2095 The syntax checking is not picky; some combinations of
2096 ridiculous and even hilarious options and modes may not be
2100 .Pa ntpkey_ Ns Ar host
2101 files are really digital
2103 These should be obtained via secure directory
2104 services when they become universally available.