Unix Tip: Configuring NTP

by Sandra Henry-Stocker

October 28, 2004 —

Send in your Unix questions today!

See additional Unix tips and tricks

Setting up a Unix system to be an NTP client is generally straightforward.
On those Unix platforms that include NTP in the default configuration,
you may only need to make a few adjustments to NTP's default configuration
file for the system to sync up to a reference time server(s) and keep
good time. On a Solaris system, for example, this involves copying a
prototype file and customizing it. You can insert the names or IP addresses
of the time server(s) you have elected to use -- whether public NTP servers
or NTP servers that you have set up on your local network -- or configure
the system to receive broadcast time updates. Once a system has been
configured, the NTP daemon will start whenever the system boots and run
continuously in the background.

Configuration of NTP servers, on the other hand, can be simple or complex,
depending on the options that you wish to use and how well you understand
the NTP service.

Many Unix systems today ship with NTP software. These include Solaris, SCO,
FreeBSD and Mac OS X. On some Linux systems, you will need to download and
install a package, such as ntp-4.1.2-5.i386.rpm, to acquire NTP services.

Once configured, the NTP service requires little or no administration. New
clients will have to be configured and an occasional verification of your
time sources may be warranted, but the service otherwise runs unattended.

Boot-time NTP

If you only want to synchronize your systems at boot time, you can configure
an ntpdate command in your start scripts. This will ensure that your system
starts up with a reasonable clock setting. On a Solaris system, this might
be done with a script like that shown below, installed as /etc/rc2.d/S73ntpdate.

------------------------------ cut here ------------------------------

#!/bin/sh

#

# synchronize date to NTP server at start-up

/usr/sbin/ntpdate -s -b -p 8 -u 129.6.15.28 216.200.93.8

------------------------------ cut here ------------------------------

In this start script, we're synchronizing our system clock to publicly
available time servers in the Washington, DC area. The options used in this
command are as follows:

option means

-s divert logging output to syslogd

-b force time stepping instead of skewing

-p specify number of time samples to be obtained from the server

-u use an unprivileged port (this can be important if privileged ports are

blocked by a firewall). NOTE: NTP uses port 123.

Notice that the ntpdate command in the script includes all the information that
it needs to run, obviating the need to insert this information from the NTP
configuration file.

On systems which boot from rc.conf files (such as FreeBSD and its derivatives),
you would need to modify additional files to use NTP. For example, you would
enable ntpdate in the /etc/rc.conf file by setting ntpdate_enable="YES".
Arguments for the ntpdate command, including the server(s) you intend to
obtain time information from need to be included in the ntpdate_flags line.
These lines might look like this:

ntpdate_enable="YES"

ntpdate_flags="-b 129.6.15.28 216.200.93.8"

Using the ntpdate command on system boot will keep your system clocks in
closer proximity and is generally a good idea. At the same time, for
synchronization, using only boot time commands is of very limited utility.
Many Unix systems run for months, even years, at a time without a reboot.
Clocks that drift can become seriously ahead or behind after months or years.

Clock Setting via Cron Jobs

A root crontab entry might be used to synchronize clocks on an hourly
basis. This practice can help keep clocks from becoming increasingly
out of synch, but represents something of a brute force approach to
synchronization due to the jumps backward and forward that might occur
once an hour as rdate forces system clocks to adjust.

An entry like that shown below will run once an hour and obtain current time
from the listed public NTP servers.

0 * * * * /usr/sbin/ntpdate -s -b -p 8 -u 129.6.15.28

Synchronization, Daemon Style

A continuously running NTP server is clearly the best choice if you want
a highly accurate and disciplined clock.

On Solaris systems, the script that starts the NTP daemon is already in
position within the /etc/rc2.d directory. It's called S74xntpd and
does not need to be modified in any way for the NTP service to run. Instead,
it looks for its configuration file (/etc/inet/ntp.conf) and, if it finds
this file, starts the daemon. Therefore, to set up NTP, all you need to do
is make sure the script finds the configuration file. This is easily done
because two prototype files are included in the /etc/inet directory. One,
/etc/inet/ntp.client, includes a single command -- multicastclient 224.0.0.1
-- and starts the client NTP service to receive multicast time messages. If
this prototype file is copied to /etc/inet/ntp.conf, the system will start a
multicast NTP client daemon whenever it is rebooted.

Before you run off and set up your ntp.conf file, you should understand that
an NTP client can be set up to work in any of three basic modes. A
"normal" NTP client (e.g., an isolated system which needs to keep accurate
time) is set up with the "server" keyword. This keyword identifies
the time sources that the client will use. Alternately, a client can be
set up to receive (instead of request) time updates with a "broadcastclient"
or "multicastclient" keyword. Each of these keywords causes the client to
listen for time updates from NTP servers.

To set up a normal NTP client, you would use server lines that look like
this:

server 129.6.15.28

server 216.200.93.8

server 64.236.96.53

Each of these lines identifies a time server to which the client will
send time requests. The NTP daemon on the client will then filter the
responses and, from them, determine the most accurate time.

NOTE: It's a good idea to include more than one server line into an NTP
client's configuration file to allow the client to disregard time responses
that appear to be significantly out of line with the other responses.
If you have greater confidence in one of the time servers listed in your
configuration file, you can attach a "prefer" keyword to any of the servers
listed. However, a preferred time source will be used only if it falls within
a certain window of accuracy determined by your NTP daemon.

server 129.6.15.28 prefer

server 216.200.93.8

server 64.236.96.53

Broadcast/Multicast NTP Clients

A broadcast or multicast NTP client listens for NTP packets from, as you
would expect, a broadcast or multicast NTP server. For such a client, the
server lines shown above are not used. Instead, a single line is used in
the ntp.conf file. This line, included in the ntp.client prototype file,
identifies the client as a multicast client:

multicastclient 224.0.1.1

The address shown (224.0.1.1) is the multicast address reserved for NTP.

To use NTP in multicast mode, you need to provide a multicast server. While
this isn't necessarily difficult, many more options exist for defining NTP
servers and a bit more work must be done to get even the most basic server running.

Setting Up an NTP Server

Fortunately for Solaris sysadmins, a prototype NTP server file is also
included in the /etc/inet directory. The file, /etc/inet/ntp.server, serves
a template for setting up an NTP server. If you copy this file to
/etc/inet/ntp.conf and then customize it to reflect the proper settings for
your network, you will end up with an NTP server that will be started by the
same script that starts the NTP client daemon.

Once configured as a broadcast or multicast server, an NTP server daemon will
issue periodic time updates to its broadcast or multicast clients.
To understand how this works, let's take a closer look at the ntp.server file.

The ntp.server File

The top 50 lines or so of this prototype file are comments that provide
information on the syntax of the operative lines. The most important
line of this file is the server line. The initial server line will look like
this:

server 127.127.XType.0 prefer

If you want to set up NTP for synchronization purposes only and are unconcerned
with whether or not the system clocks are accurate with respect to the atomic
clocks, you can configure this line to look like this:

server 127.127.1.0 prefer

The third octet in this IP address, the "1", indicates that you are electing
to use a reference clock driver of type "undisciplined local clock". This
simply means your system clock. This setting is intended for isolated networks
where no external source of synchronization is available. The 127.127.1.0
IP address is a type of loopback (as are all IP addresses in the 127.127.x.x
range), indicating that this NTP server will use its own clock as a time
reference and will make no requests to external time sources. NTP clients
using this server for time information should use the multicastclient
keyword as shown below. The 127.127.1.0 loopback can also be used on networks
where real time is unimportant, but synchronization is critical.

multicastclient 224.0.1.1

If you want your NTP server to obtain time updates from external servers,
add server lines like these (the same as those shown earlier in the column):

server 129.6.15.28 prefer

server 216.200.93.8

server 64.236.96.53

NTP servers are usually NTP clients as well. By deriving accurate time from
highly accurate (i.e., low stratum) servers, your servers are a better source
of time for your clients.

Many sysadmins favor the use of broadcast/multicast messages for NTP because
this limits the amount of NTP traffic on a network. Instead of having numerous
NTP clients individually requesting time updates from NTP servers, the servers
periodically send out the updates that can be received by all NTP clients
simultaneously. Network traffic is only one consideration in setting up NTP,
however, and the overall savings in network bandwidth is relatively small
because NTP is a lightweight protocol, using small, infrequent packets to
distribute time updates. The decision of whether or not to configure your
NTP servers and clients to use broadcast/multicast or normal (request) mode
should depend more heavily on how reliably broadcast/multicast transmissions
traverse your network and are received by your intended clients.

The decision to configure your clients to get time updates from local or
remote time sources, on the other hand, can make a significant difference
in how well NTP works for you. While you may be tempted to synchronize all
of your clients to a public time server, instead of setting up an internal
time server, this will not result in optimum synchronization. Recommended
practice is to configure one to three local NTP servers, each of which
receives time updates from different external time sources. The remainder
of the systems on your network would then configured to obtain time
information from these internal time servers, whether through requests or
broadcasts.

References

There are many good sources of information on NTP and much more to be known
and understood about how this time accuracy and synchronization service
works. I heartily recommend the following references.

From the source:

http://www.ntp.org/

http://www.eecis.udel.edu/~mills/ntp/html/index.html

From Sun's blueprint series, this 3-part white paper:

http://www.sun.com/blueprints/0701/NTP.pdf

http://www.sun.com/blueprints/0801/NTPpt2.pdf

http://www.sun.com/blueprints/0901/NTPpt3.pdf

ITworld.com