Keeping Time

With NTP

William LeFebvre

(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.
 

Constructing An NTP

Network


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/