In this implementation of NTP, the ntpd(ADMN) time daemon runs on each host on your network. These daemons communicate with each other using a hierarchical scheme in which servers on the Internet pass time data to additional servers and clients throughout the Internet.
The remainder of this chapter covers
how NTP works,
an
NTP glossary,
guidelines for using NTP,
several
examples of using NTP,
descriptions of NTP
files,
and ways to
test
and
troubleshoot
NTP.
How NTP works
The Network Time Protocol (NTP) defines a set of
procedures for synchronizing clocks on hosts connected to a
network with access to the Internet.
Some of the hosts act as time servers, that is, they provide what they believe is the correct time to other hosts. Other hosts act as clients, that is, they find out what time it is by querying a time server. Some hosts act as both clients and time servers, because these hosts are links in a chain over which the correct time is forwarded from one host to the next. As part of this chain, a host acts first as a client to get the correct time from another host that is a time server. It then turns around and functions as a time server when other hosts, acting as clients, send requests to it for the correct time.
The network time daemon
ntpd(ADMN)
is the program
running on each of the hosts in the network that, following the
conventions defined in the protocol, attempts to establish the correct time.
It does this by using the best available source of time to
synchronize the host clock with the time at zero longitude, known
as Coordinated Universal Time or UTC.
New features in this release of NTP
The Network Time Protocol (NTP) was upgraded from
V2 to V3 of the NTP protocol,
defined by RFC 1305. Significant
changes include:
If, however, your network is large, consisting of dozens or hundreds of hosts, you should set up a larger number of time servers. A good rule of thumb is to have one time server for every dozen hosts. In this case, you first establish a few stratum 2 time servers, then you establish the remaining time servers as stratum 3 time servers. Finally, all of the remaining hosts, which constitute the vast majority of the hosts on the network, become stratum 4 hosts.
Following are guidelines for setting up NTP on a network of medium size.
A
C Using NTP without Internet access
ntpd
on SCO system machines supports
a special pseudo-clock used for backup or when no other clock
source is available (for example, Internet access is not available).
The address of this clock should be set as follows in the ntp.conf
file:
127.127.1.u - Local synchronization clock driverThis driver doesn't support an actual clock, but rather allows the server to synchronize to its own clock, in essence to run without its stratum increasing to infinity. This can be used to run an isolated NTP synchronization network, where no standard time source is available, by allowing a free running clock to appear as if it has external synchronization to other servers.
By running the local clock at an elevated stratum, it can also be used to prevent a server's stratum from rising above a fixed value, thus allowing a synchronization subnet to synchronize to a single local server for periods when connectivity to the primary servers is lost.
The unit number of the clock (the least significant octet in the address) must lie in the range of 0 through 15 inclusive and is used as the stratum the local clock will run at. Note that the server, when synchronized to the local clock, will advertise a stratum one greater than the clock peer's stratum. More than one local clock may be configured (indeed all 16 units may be active at once), though this hardly seems useful.
It is recommended that the local clock be configured at a large stratum number,
for example, 10. This will minimize problems if it is being used as a backup, or
if Internet connectivity is acquired later. Since the local clock is not
connected to a reliable time source such as GPS or radio
signals, configuring
it at an elevated stratum will cause other systems to avoid it if a more
accurate source is available.
The NTP configuration file
The configuration file /etc/ntp.conf
contains information that the ntpd daemon uses at startup,
including:
The version option allows you to specify the version number to use for outgoing NTP packets. The allowed values for version_number are 1 and 2. If this option is omitted, version 3 is assumed. The minpoll option specifies that the polling interval should be kept at the minimum value allowed. This maximizes the frequency with which the host is polled and should, therefore, be used only for debugging purposes.
# # Peer configuration for 10.0.246.16 (acapulco.mynet.com) # (expected to operate at stratum 2) # peer 128.115.14.97 # clock.llnl.gov (stratum 1 server) peer 16.1.0.22 # clepsydra.dec.com (stratum 1 server)The four peer statements tell ntpd which servers to poll. The driftfile statement tells ntpd the name of the file in which to store the frequency error of the system clock. You are strongly encouraged to include this statement in the configuration file. This server is expected to operate as a stratum 2 server, because the first two servers have hardware clocks and are, therefore, stratum 1 servers.peer 10.0.246.11 # seattle.mynet.com peer 10.0.246.7 # moscow.mynet.com
driftfile /etc/ntp.drift
Keyid prompt and its associated key value in response to
the Password prompt. See
``Further examples of NTP''
for sample displays of this.
In addition to a key ID and its associated value, each
entry also contains a one-letter code indicating the type of
the key value. The precise format of an entry in the key file is:
key_ID key_type key_value
The three fields shown above are separated by any combination of blanks and tabs. Comments may appear on any line and must begin with the number sign (#).
The fields are:
Below is a sample keys file:
# # 4 M DonTTelL 6 M hElloWorld 22 M ImASecret
Hostname (IP address) Location: organization, geographic location Synchronization: machine type, clock type, synchronization protocol Service area: networks served Access policy: open or closed to the public Contact: name and email address of contact person Note: miscellaneous informationOne way to get the clock.txt file is to use ftp(TC). Below is a sample session showing how you might download this file to your host.
ftp ftp.udel.edu Connected to louie.udel.edu 220 louie.udel.edu. Name (ftp.udel.edu:user): anonymous 331 Guest login ok, send ident as password. Password: guest 230 Guest login ok, access restrictions apply. ftp> cd /pub/ntp/doc 250 CWD command successful. ftp> get clock.txt 200 PORT command successful. 150 ASCII data connection for clock.txt (10.0.246.7,1198) (90930 bytes). local: clock.txt remote: clock.txt 58409 bytes received in 8 seconds (7.1 Kbytes/s) ftp> quit 221 Goodbye.
In client mode, a host polls other hosts to get the current time. From among all of the hosts polled, the local host selects one with which to synchronize. To configure your host this way, include a server statement in your host's configuration file. The name or IP address of each time server to be polled must be specified in the server statement.
In broadcastclient mode, a host does no polling at all. Rather, it listens for NTP packets broadcast over the network. From among all of the broadcasting hosts, the local host selects one with which to synchronize. To configure your host this way, include a broadcastclient yes statement in your host's configuration file. For this mode to function, the local time servers must be configured in broadcast mode with the broadcast configuration statement.
Finally, in symmetric active mode, a host polls other hosts and responds to polls from those hosts. In addition, hosts retain time-related information about the hosts with which they are communicating. To configure your host this way, include a peer statement in your host's configuration file. The name or IP address of each time server must be specified in the peer statement.
A general guideline is to configure all hosts, except those at the highest strata of the synchronization subnet (those furthest away from stratum 1 servers), to operate in symmetric active mode. For those hosts that are at the highest strata, you have a choice: configure them to operate either in client mode or in broadcastclient mode. You should consider opting for broadcastclient mode if your hosts are on a high-speed LAN that supports broadcasts efficiently, especially if the hosts number more than twenty or so.
If you do opt for broadcastclient mode on those hosts, you must
configure the time servers on the local network to be both in
broadcast mode (to send broadcast NTP packets on the
local network) and in symmetric active mode (to poll hosts at
lower strata).
NTP address and mask facility
The address and mask configuration facility
adds various restrictions or erects barriers
between your host and other time servers.
A typical statement in the configuration file looks as follows:
restrict IP_address mask IP_address_mask flag1 flag2 . . .
Each statement adds an entry to an internal list maintained by
ntpd. Each entry in this list contains the list entry
address (the IP address following restrict),
the address
mask, and the flags. Below is a list of all of the flags and their meanings:
(source_address & address_mask) == (list_entry_address & address_mask)In words, the source address and the address mask are logically ANDed together bitwise, the list entry address and the address mask are logically ANDed together bitwise, and the two results compared for equality. If the results are equal, a match has occurred. To establish default restrictions that apply to all hosts for which no match is found, include a statement like the following in the configuration file:
restrict default flag1 flag2 . . .If a particular source address matches more than one list entry, the entry with the most one bits in the address mask is taken to be the matched entry. If a match is found, flags associated with this entry are returned.
Suppose that you are running ntpd on a host with IP address 10.0.246.16. You would like to ensure that runtime reconfiguration requests can be made only from the local host. Further, you would like the host to synchronize with only one of a pair of offsite servers or, failing that, a time source on the class B network whose address is 10.0. The following entries in the configuration file would implement this policy:
# By default, do not trust and do not allow modifications restrict default notrust nomodify# These hosts are trusted for time, but no modifications allowed restrict 10.0.0.0 mask 255.255.0.0 nomodify restrict 128.115.14.97 nomodify restrict 16.1.0.22 nomodify
# These local addresses are unrestricted restrict 10.0.246.16 restrict 127.0.0.1
The first entry is the default entry, which all hosts match and hence which provides the default set of flags. The next three entries indicate that matching hosts have only the nomodify flag set and hence are trusted for time. If the mask is not specified in the restrict statement, it defaults to 255.255.255.255. Note that the address 10.0.246.16 matches three entries in the table, the default entry (mask 0.0.0.0), the entry for net 10.0 (mask 255.255.0.0), and the entry for the host itself (mask 255.255.255.255). As expected, the flags for the host are derived from the last entry, as that mask has the most bits set.
Each restrict statement
applies to packets from all hosts, including those that are configured
elsewhere in the configuration file.
Hence, if you specify a default set of restrictions that you do
not wish to apply to the hosts you are synchronizing with,
you must override the default restrictions
for those hosts with additional restrict statements.
NTP name resolution
The ntpd daemon can specify host names
requiring resolution in peer and server statements
in the configuration file.
This task is actually accomplished by a separate program, ntpres.
When the daemon comes across a peer or server statement
in the configuration file where the host is identified by name
rather than by IP address, it records the relevant information
and continues.
When the end of the configuration file has been reached and one or more
entries requiring name resolution have been found,
ntpres is started.
The ntpd daemon continues running at the same time to
process those hosts with numeric addresses.
The ntpres program attempts to resolve each host name, meaning that it tries to obtain the IP address associated with the named host. If it succeeds in resolving the name, it reconfigures the local host to add the newly resolved host to the list of time servers to be polled. The runtime reconfiguration of the local host is accomplished using the same mode 7 runtime reconfiguration facility that ntpdc uses. If ntpres is at first unable to resolve a hostname, it retries periodically until it succeeds or until it determines that the name cannot be resolved.
There are several configuration requirements if ntpres is to be used. The pathname of the ntpres program must be made known to the daemon with the resolver statement in the configuration file. Also, mode 7 runtime reconfiguration must be enabled with the requestkey statement and a list of valid keys (valid keys are specified in the keys file).
The following fragment might be added to /etc/ntp.conf to accomplish this:
resolver /etc/ntpres keys /etc/ntp.keys requestkey 65535Note that ntpres sends packets to the server with a source address of 127.0.0.1. If you are using the address-and-mask facility in the configuration file, you must take care not to restrict modification requests from this address or ntpres fails.
Here is the ntp.conf file for seattle.mynet.com:
# # Peer configuration for 10.0.246.11 (seattle.mynet.com) # peer 192.240.4.1 # ntp1.ossi.com peer 129.189.134.6 # ntp.olivetti.comdriftfile /etc/driftfile
This next scenario is the complete configuration for mynet.com. The configuration files here configure mynet.com to match the topology discussed in ``NTP guidelines''. All hosts can be configured dynamically with ntpd. There are no restrictions on which hosts can be designated as time servers in a given host's configuration file.
Here is the ntp.conf file for acapulco:
# # Peer configuration file for 10.0.246.16 (acapulco.mynet.com) # peer 128.115.14.97 # clock.llnl.gov peer 16.1.0.22 # clepsydra.dec.com peer seattle.mynet.com peer moscow.mynet.comHere is the ntp.keys file for acapulco:broadcast 10.0.246.255
driftfile /etc/ntp.drift resolver /etc/ntpres keys /etc/ntp.keys requestkey 65534 controlkey 65535
2313 M APassword 65534 M NoSecret 65535 M BadKeyHere is the ntp.conf file for seattle:
# # Peer configuration for seattle (10.0.246.11) # peer 129.189.134.6 # ntp.olivetti.com peer 192.240.4.1 # ntp1.ossi.com peer acapulco peer moscowHere is the ntp.keys file for seattle:broadcast 10.0.246.255
driftfile /etc/ntp.drift resolver /etc/ntpres keys /etc/ntp.keys requestkey 65534 controlkey 65535
2313 M APassword 65534 M NoSecret 65535 M BadKeyHere is the ntp.conf file for moscow:
# # Peer configuration file for 10.0.246.7 # moscow.mynet.com # peer 130.43.2.2 # apple.com peer 192.52.195.10 # norad.arc.nasa.gov peer seattle.mynet.com peer acapulco.mynet.comHere is the ntp.keys file for moscow:broadcast 10.0.246.255
driftfile /etc/ntp.drift resolver /etc/ntpres keys /etc/ntp.keys requestkey 65534 controlkey 65535
2313 M APassword 65534 M NoSecret 65535 M BadKeyHere is the ntp.conf file for chicago:
# Peer configuration used by all stratum 3 # servers at mynet.com # broadcastclient yes broadcastdelay 0.0500 driftfile /etc/ntp.drift resolver /etc/ntpres keys /etc/ntp.keys requestkey 65534 controlkey 65535Here is the ntp.keys file for chicago:
2313 M APassword 65534 M NoSecret 65535 M BadKey
precision -6The precision statement sets the value of sys.precision. The variable sys.precision is the base two logarithm of the expected precision of the system clock. The default value is -6 on all servers. The sys.precision variable is defined in RFC 1305.
The NTP protocol makes use of sys.precision in several places. For one, sys.precision is included in packets sent to peers and is used by them as a kind of quality indicator. When faced with selecting for synchronization purposes one of several servers, all of which are at the same stratum and offer about the same network path delay, clients prefer to synchronize to those claiming the smallest (most negative) value of sys.precision. The effect is particularly pronounced when all the servers are on the same LAN. Hence, if you run several stratum 1 servers, or three or four stratum 2 servers, and you would like clients to prefer one of these over the others for synchronization, you can accomplish this by decreasing the value of sys.precision on the preferred server or by increasing this value on the other servers, or by doing both.
The other tuning parameter is the antihop aperture and is derived from sys.precision and NTP.MAXSKW using the following equation:
antihop aperture = 2 ** sys.precision + NTP.MAXSKWThis equation says that the antihop aperture is equal to 2 raised to the sys.precision power plus NTP.MAXSKW.
Making the antihop aperture larger makes it less likely that the host will ``hop'' from the server it is currently synchronizing with to a different server. Unfortunately, this also increases the probability that the host continue to synchronize with a server whose clock is no longer accurate.
Making the antihop aperture smaller allows the host to hop more
freely
from server to server, but this can also cause it to generate a fair bit
more NTP packet traffic than necessary and to no good purpose.
Given the agreement among current stratum 1 NTP servers and
the performance typical of the Internet,
it is recommended that the antihop aperture be
kept between 0.020 and 0.030. The default value is about 0.026.
NTP query commands
Two query programs,
ntpq(ADMN)
and
ntpdc(ADMN),
are available for use by the network administrator.
The ntpq command sends queries and receives responses
using NTP standard mode 6 control messages, while the
ntpdc command uses NTP private mode 7 messages
to send its requests.
The format and content of these messages are specific to
ntpdc.
This command allows you to inspect a wide variety of internal counters
and other state data. It also provides you with an
interface to the runtime reconfiguration facility.
Both ntpdc and ntpd use seconds as the unit of time, both when reading the configuration file and when doing runtime reconfiguration. Both programs also print values in seconds. On the other hand, ntpq prints all time values in milliseconds. You must, therefore, take special care to convert values output by ntpq from milliseconds to seconds before modifying the configuration file, either manually or with ntpdc.
The ntpd daemon is designed to allow its configuration to be
modified at runtime.
Nearly everything that can be configured in the configuration
file ntp.conf may be altered using ntpdc.
Further examples of NTP
This example demonstrates the use of ntpq
and ntpdc to list the
servers that chicago.mynet.com is currently polling.
The server marked with an asterisk (*) is the one
that chicago is currently synchronizing with.
chicago
is also listening for broadcast packets on the subnet with IP
address 10.0.246,
but no packets are currently being broadcast there.
Note the difference
in the units used by
ntpq and
ntpdc to display delay, offset, and dispersion.
The former uses milliseconds, whereas the latter uses seconds.
chicago# ntpq ntpq> peerremote refid st when poll reach delay offset disp ========================================================================== 10.0.246.255 0.0.0.0 16 never 64 0 0.0 0.00 64000 *acapulco.mynet.com clepsydra.dec 2 53 64 376 81.1 -1.00 12.4 +moscow.mynet.com norad.arc.nas 2 11 64 37 41.2 30.00 7504.3
chicago# ntpd ntpd> peer
remote local st poll reach delay offset disp =========================================================================== *acapulco.mynet.com 10.0.246.16 2 64 376 0.0811 -0.001003 0.0124 -moscow.mynet.com 10.0.246.7 2 64 37 0.0412 0.030001 7.5043 ^10.0.246.255 0.0.0.0 16 64 0 0.0000 0.000000 64.000
This information tells us, among other things, that:
Another sign of more than one entity setting or slewing the clock is the following message in the syslog file:
Previous time adjustment did not completeOne of the following messages is issued when the clock of another host (the remote clock) is off by more than 1000 seconds from the clock on the local host (the local clock):
Clock appears to be number_of_seconds seconds fast, something may be wrong
Clock appears to be number_of_seconds seconds slow, something may be wrongIn this situation, ntpd will not try to synchronize with that host. If you want to synchronize with that host, you will need to set the local clock to within 1000 seconds of the remote clock. You can accomplish this by using the ntpdate(ADMN) command.
For example, if the host apple.com at IP address 130.43.2.2 is a host you wish to poll in symmetric active mode and you know that apple.com is running ntpd instead of ntpd, you should include the following configuration statement in your local host's ntp.conf file:
peer 130.43.2.2 version 1 # apple.com (running ntpd)This statement ensures that version 1 NTP packets are sent by your local host to apple.com.
For interoperability with hosts running ODT 2.0 and 3.0, you must specify ``version 2'' in your local host's ntp.conf file. For example, if the host apple.com at IP address 130.43.2.2 is a host you wish to poll in symmetric active mode and you know that apple.com is running ODT 2.0, you should include the following configuration statement in your local host's ntp.conf file:
peer 130.43.2.2 version 2 # apple.com
---------------------------------------------------------
Manual page Purpose
---------------------------------------------------------
ntpdate(ADMN) set the date and time via NTP
ntpq(ADMN) standard NTP query program
ntptrace(ADMN) trace a chain of NTP hosts
back to their master time source
ntpd(ADMN) NTP daemon
ntpdc(ADMN) query/control program for the NTP daemon
To get more information about NTP and related protocols,
see the following Requests for Comments (RFCs).
-------------------------------------------------
RFC Title
-------------------------------------------------
1059 Network Time Protocol Version 1
specification and implementation
1119 Network Time Protocol Version 2
specification and implementation
1128 Measured performance of the Network Time
Protocol in the Internet system
1129 Internet time synchronization: The Network
Time Protocol
1305 Network Time Protocol Version 3