Home > Linux > How to setup an NTP Server?

How to setup an NTP Server?

The Network Time Protocol is defined in RFC1305 and allows the transfer and maintenance of time functions over distributed network systems. One of the most widely used NTP servers is ntpd (ntp.isc.org), which also provides Simple NTP (RFC2030) and is a common package of most Linux distributions. The NTP server figures out how much the system clock drifts and smoothly corrects it with delicate accuracy, as opposed to large adjustments once every few hours.

The following chapter details how to configure the local NTP daemon to access external time servers and to provide the clients on the internal network the ability to synchronise from the server.

Basic Configuration

Just like any time piece, the NTP server maintains a time service where the synchronisation and maintenance of time is paramount. Before any time services are configured, its important that the server should have an initial state which has been synchronised with another time source reference. The following command will synchronise the local system time against another server, ensuring nearest possible time is available before configuring the NTP server.

[bash]# ntpdate -b pool.ntp.org

Before we adjust any configuration files, its always recommended that we make a backup of the original in case things go wrong, then we can edit the file and make changes as required.

[bash]# cp /etc/ntp.conf /etc/ntp.conf.original
[bash]# vi /etc/ntp.conf

Finding a Time Source

One of the most difficult issues that people face with NTP is finding a time server that allows home and small office users to publicly synchronise off them. Enter the NTP Pooling Project located at http://www.pool.ntp.org. The NTP Pool is a collection of over 220 publicly accessible NTP servers distributed throughout different regions of the world. The DNS records for the NTP Pool are rotated hourly with different servers being allocated into each pool and region.

The advantages of the NTP Pool are:

  • that all the available servers will load balance,
  • you don’t need to spend hours hunting for any public servers, and
  • you only need to remember one set of records for all the servers.

The default configuration for ntpd servers after version 4.2 uses the NTP Pool for the default server sources.

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

If you have access to other NTP servers which are geographically closer and you can synchronise from them, you should substitute the server values above. Alternately the NTP Pools are also broken into geographical Pools which may serve as a quicker time source, see here: http://ntp.isc.org/bin/view/Servers/NTPPoolServers

Access Controls

The NTP server is a network application that provides a resource to other networked systems and clients, as such we need to ensure that some security measures are enforced. The NTP configuration has adjustable access controls that define all the default controls and those for allowable clients and remote servers.

The following restrict statement defines the suggested access controls for all default connections.

restrict default kod nomodify notrap noquery nopeer

The following table lists and defines some of the more commonly used access control parameters.

Parameters Definitions
ignore Deny all packets and queries
kod Send Kiss-Of-Death packet on access violation
nomodify Deny ntpq / ntpdc queries that attempt to modify the server
notrap Deny control message trap service
noquery Deny all ntpq / ntpdc queries
noserve Deny all queries – except ntpq / ntpdc
notrust Deny access unless cryptographically authenticated (ver 4.2 onwards)
nopeer Deny all packets that attempt to establish a peer association
Caution !! In NTP versions prior to 4.2, the notrust option meant not to trust a server/host for time. In NTP versions 4.2 and later, the notrust option means cryptographic authentication is required before believing the server/host. Unless using cryptography, do not use the notrust option, your client requests will fail.

To allow full control to the localhost, add the following entry to the configuration.


The NTP Pool servers have been listed as a time source already (ver 4.2 onwards), and they too need restrictions applied so the local server can synchronise from them. Ensure the access control parameters are strict enough that the remote servers can only be used for queries.

restrict 0.pool.ntp.org mask nomodify notrap noquery
restrict 1.pool.ntp.org mask nomodify notrap noquery
restrict 2.pool.ntp.org mask nomodify notrap noquery

To allow all the workstations inside the internal private network to be able to query the time from your server, use the following access control rule (adjust subnet if needed).

restrict mask nomodify notrap

Finally we need the following declarations in the /etc/ntp.conf file.

server # local clock
fudge stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
keys /etc/ntp/keys

The above configuration parameters are as follows:

server Specifies that a server is running on the host (own local clock)
fudge Passes additional information to the clock driver
stratum 10 Manually sets the Stratum the server should operate at (1-15)
driftfile Specifies the location of the frequency file
broadcastdelay Sets the propagation delay from the server when broadcasting
keys Store a list of keys needed for any cryptographic links

The Strata

The world of NTP is hierarchical with the primary servers at the top keeping the master time, and distributing the time down to the secondary servers and so forth until your little workstation synchronises in the corner office. Each server participating in the hierarchy are allocated a stratum, with stratum 1 being the master servers, stratum 2 the secondary servers, down to the lower end of stratum 15. A stratum 1 server uses an external time source (GPS, etc..) which is introduced into the server and then used to propagate the time signals. Stratum 2 servers draw their time from the higher (1) stratum servers.

When determining the stratum of your server, firstly consider who you are providing time to? If you are only using the system for yourself and passing it on to a few workstations, then your stratum can be safely left at 10. If you are using the system for a large scale network, then plan your time servers and strata effectively.

Starting NTP

The server is now fully configured and ready to start. If you have not already done an initial synchronisation of time (before running the daemon), you should do so now. The initial sync only needs to be done once before the server is started for the first time, not each time it starts.

[bash]# ntpdate -b pool.ntp.org

You should now set the runlevels required for the ntpd service, then restart it.

[bash]# chkconfig –level 2345 ntpd on
[bash]# /etc/init.d/ntpd restart
Note !! The NTP server uses UDP packets to query time servers on port 123. Depending on your Linux configuration, the initscripts for the ntpd service may have iptables commands to allow ntpd to access the external time servers.

You can check which runlevels the service will be active with the following command.

[bash]# chkconfig –list ntpd

To see if the service started successfully, you should check the system log file.

[bash]# grep ntpd /var/log/messages
galaxy ntpd[1110]: ntpd 4.2.0a@1.1196-r Thu Feb 23 04:42:00 EST 2006 (1)
galaxy ntpd[1110]: precision = 2.000 usec
galaxy ntpd[1110]: Listening on interface wildcard,
galaxy ntpd[1110]: Listening on interface wildcard, ::#123
galaxy ntpd[1110]: Listening on interface lo,
galaxy ntpd[1110]: Listening on interface eth0,
galaxy ntpd[1110]: kernel time sync status 0040
galaxy ntpd[1110]: frequency initialized 0.000 PPM from /var/lib/ntp/drift

You can now query the NTP server with the ntpq (query) tool. The output display after ntpd has been (re)started will be similar to the first table. As ntpd is allowed to run for a while, the table will start to fill with synchronisation details.

[bash]# ntpq -pn
remote refid st t when poll reach delay offset jitter
============================================================================== .INIT. 16 u – 64 0 0.000 0.000 4000.00 .INIT. 16 u – 64 0 0.000 0.000 4000.00 .INIT. 16 u – 64 0 0.000 0.000 4000.00 LOCAL(0) 10 l – 64 0 0.000 0.000 4000.00
remote refid st t when poll reach delay offset jitter
* 2 u 66 256 377 470.247 32.058 33.497
+ 3 u 254 256 377 217.646 -3.832 2.734
+ 2 u 2 256 377 258.208 2.395 47.246 LOCAL(0) 10 l 56 64 377 0.000 0.000 0.002

The above output shows a properly synchronised time server drawing from NTP Pool allocated sources. You will notice our server is running at a stratum of 10.

Note !! Your internal workstation computers will not be able to use the server as a synchronisation source until the LOCAL(0) clock has stable time. This may take up to 15 minutes after starting the NTP daemon.

The server can be tested from another Linux workstation by issuing the following synchronisation command.

[bash]# ntpdate

If the client computer does not get the time from the server, check that the server and client have access through any firewall settings.

Client Configuration

Before any client can successfully synchronise with the NTP server, the server’s time must be stable. It may take a server up to 15 minutes before it can be used as a time source, after ntpd has been (re)started.

Linux Client

To configure a Linux client to use the new server as a time source, the configuration file for the client should at least contain the following entries.

[bash]# vi /etc/ntp.conf
restrict default ignore
restrict mask nomodify notrap noquery
driftfile /var/lib/ntp/drift

The Linux client will also need to have the ntpd service started.

Microsoft Client

To configure a Microsoft Windows (XP) client, follow the sequence of commands below.

Note !! These commands are tested on Windows XP, and may not be specific to every version of Windows.
C:\>net time /setsntp:
The command completed successfully.
C:\>net time /querysntp
The current SNTP value is: command completed successfully.
C:\>net stop w32time && net start w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.The Windows Time service is starting.
The Windows Time service was started successfully.

The standard time query interval for Windows (XP) is one query every 7 days, which for time critical applications and environments is ineffective. To adjust the time interval for Windows (XP), a registry value needs to be adjusted.

Windows (XP) stores the following registry key in a hexadecimal format, which converted to decimal will amount to the time in seconds between time queries. Select the new time (in seconds) that you require the Windows (XP) system to poll the server, then convert it to hexadecimal (86400 seconds is 1 day). This should be the “DWORD” value.

Warning !! Adjusting the Windows registry may cause your computer system to become unstable, do so at your own risk.

The “Windows Time” service in Windows (XP) should be set to start automatically on each system boot. The event log should be viewed for any errors that may occur. See this article for more information: http://support.microsoft.com/kb/323621

For more technical articles, news and forum discussion logon

Note !! If the service does not appear to be synchronising with the Linux server, ensure that the firewall is allowing any required connections.
Categories: Linux
  1. No comments yet.
  1. April 4, 2011 at 7:53 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: