Network Time Protocol
Network Time Protocol
Version: | – ntpd 4.2.0 |
Basic Configuration
Starting the Server
Client Configuration
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 |
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.
restrict 127.0.0.1 |
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 255.255.255.255 nomodify notrap noquery restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 2.pool.ntp.org mask 255.255.255.255 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 192.168.1.0 mask 255.255.255.0 nomodify notrap |
Finally we need the following declarations in the /etc/ntp.conf file.
server 127.127.1.0 # local clock fudge 127.127.1.0 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 |
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, 0.0.0.0#123 galaxy ntpd[1110]: Listening on interface wildcard, ::#123 galaxy ntpd[1110]: Listening on interface lo, 127.0.0.1#123 galaxy ntpd[1110]: Listening on interface eth0, 192.168.1.1#123 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 ============================================================================== 80.26.104.184 .INIT. 16 u – 64 0 0.000 0.000 4000.00 128.95.231.7 .INIT. 16 u – 64 0 0.000 0.000 4000.00 64.112.189.11 .INIT. 16 u – 64 0 0.000 0.000 4000.00 127.127.1.0 LOCAL(0) 10 l – 64 0 0.000 0.000 4000.00 |
remote refid st t when poll reach delay offset jitter ============================================================================== *80.26.104.184 217.127.32.90 2 u 66 256 377 470.247 32.058 33.497 +128.95.231.7 140.142.2.8 3 u 254 256 377 217.646 -3.832 2.734 +64.112.189.11 128.10.252.6 2 u 2 256 377 258.208 2.395 47.246 127.127.1.0 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.
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 192.168.1.1 |
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 |
server 192.168.1.1 restrict default ignore restrict 127.0.0.1 restrict 192.168.1.1 mask 255.255.255.255 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.
These commands are tested on Windows XP, and may not be specific to every version of Windows. |
C:\>net time /setsntp:192.168.1.1 The command completed successfully. |
C:\>net time /querysntp The current SNTP value is: 192.168.1.1 The 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 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.
Adjusting the Windows registry may cause your computer system to become unstable, do so at your own risk. |
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient] “SpecialPollInterval”=dword:00093a80 |
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
If the service does not appear to be synchronising with the Linux server, ensure that the firewall is allowing any required connections. |
Leave a comment