(Original scanned images page1 page2 page3 page4)
Are you one of those exceedingly exact folks who has every clock in the house set to exactly the same time? While hopping between machines on your network, have YOU noticed they often have different notions of the correct time? If you answered yes to both, the Network Time Protocol (NTP) is for you. Keeping consistent time across the enterprise is more than just a good idea. A file
server will timestamp a write to a file with what it believes is the current time. But if a server's clock has a substantially different time than the clients, project applications (such as make) can become confused- It can lie a serious problem for some applications to come across a file with a timestamp ten minutes in the future.
A comparison of log entries can be complicated when clients with clocks that differ by Minutes are logging to the same host. Attempting to chain together a sequence of events while looking at these logs is often futile. Other distributed systems such as Kerberos, also rely on clocks being synchronized between hosts.
David Mills first specified NTP in Request for Comment (RFC) 958, published in 1985. Since then, it has enjoved a slow but stead\, increase in popularity among the UNIX crowd. The protocol itself is rather involved, but it does in excellent job of calculating the correct current time, even taking propagation delays into account.
NTP relies on access to in accurate timekeeping device. The protocol can provide amazingly accurate synchronization between clients and the timekeeper accuracies usually are good to within
\cross a LAN,
milliseconds, When WAN,,; get involved, it may degrade to tens of milliseconds. It is as accurate as most applications need.
For \,cars, NTP has been just another publicly available
tool. Recently, however, several UNIX vendors have integrated ,in NTP server into their standard distributions. NTP is now part of Digital UNIX, HP-UX and Solaris All ),on need to do is configure and start it.
The most recent release of the software is xntp3 version 5.91 This is in implementation of NTP version 3 as described in RFC 1305. Part of the protocol allows for cryptographic authentication, so parts of xntp3 fall victim to the same export restrictions that hound Secure Shell (ssh), Pretty Good Privacy (PGP), Data Encryption Standard (DES), and even Web browsers.
The NTP Protocol
Before understanding how the daemon works, we need to know a few things about the protocol. The basic philosophy is that there is a universal notion of time to which all machines should synchronize: Universal Coordinated Time (UTC). The catch is that NTP does not assume my one server is a correct source of UTC Rather than trying to synchronize one host with mother, each NTP server tries to svnchronize with UTC independently through the best sources of information the server can access.
The NTP servers are structured in a hierarchy rather than in a flat space or in a cloud. Each server assigns itself a "stratum" level that corresponds with its distance front a UTC source. Stratum 1 servers have direct access to a source for UTC time, such as a radio receiver. Stratuni 2 servers receive their time inforniation from stratum I servers, while stratum .1 servers listen to stratum 2, and so on. The number of strata is limited to 15.
An NTP
host can operate as both a client and a server. Typically, an NTP client
will synchronize with one server in its configuration. The choice of server
depends on a number of factors, including stratum level
measured
network delay, and claimed precision. However, if three or more servers
are available, the client will employ a voting algorithm to ensure its
server of choice is not providing in outrageous time value.
As a client,
an NTP host synchronizes with other servers. As a server, it permits other
NTP hosts to synchronize with itself. There are two types of association
modes, between NTP hosts, In a client-server association, the client only
receives time information from the server. In the symmetric-active mode,
each NTP host acts as a server to the other and the two hosts exchange
time information. The typical arrangement for a pool of time servers is
for each to use a symmietric-active association with the others in the
pool and to use a client association with at least three lower-stratum
servers. The most robust configuration would have each server use a client
association with a different set of three lower-stratum servers.
User workstations
typically will not be slated for the role of NTP server. These will be
configured to use a client a
association
with each NTP server in the pool. Client-only hosts also can be configured
to receive synchronization information via broadcast or multieast packets.
In a network of 100 clients and three time servers, for example, there
are more than 300 associations and packet exchanges. If the time servers
simply broadcast their information, the amount of traffic required to maintain
the 100 clients reduces dramatically. The decrease in accuracy is not significant
for most applications.
Configuring NTP
At the heart of xntp3 is the dacnion xntpd The program typically is started at boot time and consults /etc/~tp.conf for configuration information. This file can configure many aspects of xntp operations. We will hit only the highlights here. The peer statement sets up a symmetric-active association with the named server. The server statement instructs the host to act as a client using the specified server as a source of information. Some of the more common statements are summarized in Figure I (p. 26).
A server
can be configured to broadcast or multicast its information with the statement
broadcast
followed
by the destination address. The address should be either the broadcast
address of a directly connected network (192.168.1.255, for example), or
the multicast address that has been assigned to NTP (224.0.1.1). A client
can be configured to listen to broadcast NTP packets with just the statement
broadcastclient.
Multicast
clients are configured with multicastclient
.
The
multicast address for this statement defaults to 224.0. 1. 1, although
it can be specified explicitly in the statement.
The peer
,Prv(,r,, and broadcast lines allow you to specify a version number and
the version of tile NTP protocol to use ( 1, 2, or 3). This is provided
primarily for backward compatibilityIf you are using recent versions of
xntp everywhere, let the version default to 3. The prefer, keyword call
be, used to indicate which server should be used when all means of comparison
are equal.
It is,
important to declare the driftfile in the configuration. As xntpd runs,
it continually adjusts the system clock through regular uses of the kernel
call
adjtime
and it calculates an average observed clock offset every hour. This offset,
or drift, is recorded in the drift file. If xntpd loses its synchronization
with all
available
time servers, it will continue to run and will repeatedly apply the drift
adjustment recorded in the drift file. Most system clocks do not measure
time well, but they usually are consistent. The xntpd daemon can continue
to benefit these systems even if none of the time servers on the network
are reachable.
The Simplest configuration would be found oil a broadcast client. The first line declares the driftfile and the second specifies the client type:
driftfile /etc/ntp.drift
broadcastclient
The NTP
protocol allows for cryptographic authentication through DIES, MD5 and
other ciphers. The xntpd server also can be configured to limit its interaction
to a specific block of IBM addresses. All of these can be specified through
the
ntp.conf file.
Implementing
NTP on your network might he casier than you think. The first task is to
find a set of NTP servers outside your organization that you can use. If
you are part of a larger corporation, chances are tile central networking
group already has set ill) -i pool of time servers. If not, check with
your Internet service provider (ISP). Many of them have time servers (also
called "chirners") established on their networks. Finding a nearby chimer
is best, because the accuracy is better and the traffic demands less. It
is best to have access to several time servers; three is a minimum. Besides
your ISP, there are a large number of publicly accessible time servers
on the Internet. Lists of stratum 1 and stratum 2 servers are available
from the NTP Web page (See References). If accuracy to the millisecond
is not that important, you should be happy with a straturn 2 server.
Start with a list of stratum I and stratum 2 servers you -ire allowed to access. Include in this list ,my chimers available oil your local intranet and through your ISP Let's call these A, B, C, and so on. Identify at least three machines that can let as time servers for your network. If you plan to use broadcast clients everywhere, you will need at least one time server on each subnet Remember that routers do not propagate broadcasts. We will call these time servers chime-1 chime-2 and chime-3 Configure your chimers to act as clients with the servers from the first batch using server, statements. Overlap as little as possible. Then add peer, statements to have cacti of your chimers peer with the others. An example for chime-] is given in Figure 2. Finally,configure each of your clients as broadcast clients, as discussed earlier.
You even
can get by with less than this. If you have only a handful of machines
and redundancy is not important, then choose just one server and do not
con-
figure
any symmetric peers NIN, workstation at home contains only one "server"
line to synchronize the host with lily ISP's chillier. NTP is very flexible
Once you have set tip your NTP network, you call monitor its health front any client with the interactive utility xntpdc. The most commonly used command is peers, which lists inforniation about every server this host interacts with, whether they are symmetric-active or server only. By default, xntpdc interacts with the local xntpd process, hut the command server directs it to talk to a different host's xntpd process. The too] is able to change aspects of the server's configuration is well.
External Time Sources
You call set tip a stratum I server if you have hardware that is capable of calculating UTC. There is quite a variety of products, including WWV receivers and Global Positioning System (GPS) receivers. The xntp3 distribution includes about 25 drivers for various products. Tile physical connection varies widely with each product - most using either a serial line or a special bits peripheral, You will have to read both the vendor's and the xntp driver's documentation You specify one of these sources of information in ntp.conf as if it were a server. Rather than using a conventional 11) address, use the special network 127.127.0.0. The third octet of the address indicates tile driver type and the fourth octet is a unit number For example server 127 .127.5. 1 will use a TrueTime GPS receiver via tile file /dev/true1 I - You also would need to link /dev/true1 to the actual device file.
Isolated networks might have 110 Way to reach a straturn 1 server, either because there is a firewall Hocking the packets or because there is no Internet connection. In this case there are two options. First, obtain in external time source and set up a stratum I server. Second, declare one of your machines as tile official source of time and use its system clock as tile UTC reference for all other NTP clients. A special driver is provided in xntp3 for this purpose, called the local clock driver, or tvpe 1. You would set up your refcrence machine with the configuration statement server 127. 127.1.1. By default, this driver operates ,it strattun 3 to ensure that it does not disturb other servers with a genuine time source.
Supported
Systems
The xntp3
package runs on litany different UNIX
platforms.
Certain systems (for example, SunOS 4) are
notorious
for their poor timekeeping abilities and may require tuning one or two
kernel variables. Solaris 2.0 now includes xntp3 as part of the standard
operating system, as does Digital UNIX 4.0C and HP-UX (10.1 and later).
NTP is
a great way to keep tune oil your systems It is flexible but easy to configure.
The source package also is reasonahly easy to configure and instalL When
it conics to keeping accurate time NTP is the best Way to go.
References
- Mills,
D.L.
Network Time Protocol (Version 3) specification, implementation and analysis.
Network
Working Group Report, RFC1305. University of Delaware, March 1992.
- Time
Server Web Site, http://www.eecis.udel.edu/~ntp/