NTP server configuration

What is NTP?

Accurate system time is essential for the software and applications installed on the server to be able to operate correctly. NTP synchronizes very critically for financial and telemetric applications. The issue with system clock is with the passage of time; the system clock may become inaccurate owing to a variety of reasons like power failures, cheap hardware clocks, etc. To buy a uber accurate and costly crystal clock for each system is not a viable solution. This is where the Network Time Protocol (NTP) comes into the picture.

What are NTP server and client?

The NTP server: As said earlier to have an accurate and costly clock for each and every system is not a good solution. Thats where we have NTP servers on the Internet which have precise system times with the help of costly time crystal clocks.  These servers intern synchronize with other NTP servers to have accurate system clocks.

The NTP client: These are just NTP agents which keep local system time synchronize with internet-based or local NTP servers for keeping local time not to drift away.

What actually NTP service do constantly monitor Internet-based NTP servers

operates on UDP port number 123 and is used to synchronize system time with a reference source. The reference source, in this case, could be another server or a GPS clock.

The package is generally installed on the server by default for Redhat based systems. We can look for it in the rpm –qa command to verify its existence:

[root@linuxnix ~]# rpm -qa | grep -e "^ntp"
ntp-4.2.6p5-10.el6.centos.x86_64
ntpdate-4.2.6p5-10.el6.centos.x86_64

Install NTP in Linux Redhat/Centos

If this package is not installed, you may install it manually from the default repository available.

yum install ntp

Install NTP in Linux Ubuntu/Debian

apt-get install ntp

NTP runs as a daemon based service on the system. The daemon name is ntpd. To check if the service is running execute the following command:

[root@linuxnix ~]# service ntpd status
ntpd is stopped

Now that we’ve verified that ntp is installed on our system we now head to http://www.pool.ntp.org/en/ to choose a ntp server closest to us which we’ll be using.

 

I being in India have looked up servers available for this region. You may please choose the server closest to the area where you are located.

Let’s take a look at the ntp configuration file /etc/ntp.conf. The ntp.conf file is a bit long file with so many empty lines and comments. The below grep command will filter out those blank lines and comments for you.

[root@linuxnix ~]# grep -Ev '^(#|$)' /etc/ntp.conf
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys

In case you are not familiar with regular expressions, the grep -v command omits any lines beginning with comments (indicated by ^#) and blank lines (indicated by ^$) from the output. This makes the file easier to read because the default file usually tends to have many commented lines and blank lines.

We’ll edit this file update our selected servers in the server section.

[root@linuxnix ~]# grep -vE '^(#|$)' /etc/ntp.conf | grep -E 'server|192'
restrict 192.168.87.0 netmask 255.255.255.0 nomodify notrap
server 0.asia.pool.ntp.org iburst
server 1.asia.pool.ntp.org iburst
server 2.asia.pool.ntp.org iburst
server 3.asia.pool.ntp.org iburst

We also modify the restrict directive to allow other client servers to synchronize their time with this ntp server. The nomodify notrap statements suggest that the clients are not allowed to be used as peers to ntp synchronize. This would come into the picture if we were to use this system as an NTP server.

We also add a log file to record any issues with the NTP daemon.

[root@linuxnix ~]# grep -vE '^(#|$)' /etc/ntp.conf | grep 'log'
logfile /var/log/ntpd.log
[root@linuxnix ~]#

If you are using iptables, then add appropriate rules to allow traffic on port 123 which is the port on which the ntp service listens on.

Now let’s turn on the service and enable it on boot.

[root@linuxnix ~]# service ntpd start
 Starting ntpd:                                             [  OK  ]
 [root@linuxnix ~]# chkconfig ntpd on
 [root@linuxnix ~]# chkconfig ntpd --list
 ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

As shown by the below netstat output we find that the service is listening on port 123.

[root@linuxnix ~]# grep -w ^ntp /etc/services
ntp 123/tcp
ntp 123/udp # Network Time Protocol
[root@linuxnix ~]#
[root@linuxnix ~]# netstat -tulpn | grep ntpd
udp 0 0 192.168.87.144:123 0.0.0.0:* 1885/ntpd
udp 0 0 127.0.0.1:123 0.0.0.0:* 1885/ntpd
udp 0 0 0.0.0.0:123 0.0.0.0:* 1885/ntpd
udp 0 0 fe80::20c:29ff:fe62:f03:123 :::* 1885/ntpd
udp 0 0 ::1:123 :::* 1885/ntpd
udp 0 0 :::123 :::* 1885/ntpd 

While working with ntp perhaps the most common that you would encounter is the ntpq command. This is used to monitor the ntpd daemon and determine it’s performance.

We may use this utility by invoking it as a command or an interactive shell.

To view, the available ntp peers (servers from which time is being synchronized) use the ntpq –p command or type peers in the ntpq interactive shell.

ntpq> peers
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*y.ns.gin.ntt.ne 249.224.99.213   2 u   66   64    3  448.731  323.707 141.653
+hachi.paina.net 131.113.192.40   2 u   68   64   16  407.070  348.327 258.477
-ntp.gnc.am      195.43.74.123    2 u    4   64    7  560.334  672.630 406.733
+ntp.hoster.kg   202.112.29.82    3 u   73   64   16  467.187  431.636 294.263
ntpq> exit
[root@linuxnix ~]# ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-y.ns.gin.ntt.ne 249.224.99.213   2 u  114   64    1  514.841  137.647  83.567
+hachi.paina.net 131.113.192.40   2 u   51   64    1  573.896  336.766  69.322
*ntp.gnc.am      195.43.74.123    2 u   47   64    1  539.843  409.441 100.579
+ntp.hoster.kg   202.112.29.82    3 u   52   64    1  511.547  364.269  64.297

 

Let’s understand the various fields reported in the above output one by one:

  • The * indicates that this particular association is the chosen ntp source.
  • The  + indicates that this ntp peer is a candidate.
  • An empty space indicates that the server is unreachable and therefore rejected.

Refid: The refid field is the Reference ID which identifies the server or reference clock with which the remote peer synchronizes, and its interpretation depends on the value of the stratum. For stratum 0 (unspecified or invalid), the refid is an ASCII value used for debugging. Example: INIT or STEP. For stratum 1 (reference clock), the refid is an ASCII value used to specify the type of external clock source. Example: NIST refers to NIST telephone modem. For strata 2 through 15, the refid is the address of the next lower stratum server used for synchronization.

St: The st field is the stratum(level or layer) of the remote peer. Primary servers are assigned stratum 1. A secondary NTP server which synchronizes with a stratum 1 server is assigned stratum 2. A secondary NTP server which synchronizes with a stratum 2 server is assigned stratum 3. Stratum 16 is referred to as indicates being unsynchronized. Strata 17 through 255 are reserved.

t: The t field is the type of peer: local, unicast, multicast, or broadcast.

poll: The poll field is the polling interval (in seconds). This value starts low (example: 64) and over time, as no changes are detected, this polling value increases incrementally to the configured max polling value (example: 1024).

reach: The reach field is the reachability register. A reach value of 377 indicates that all polling attempts were successful.

delay: The delay field is the current estimated delay between sending a request and a receiving a reply from an ntp peer.

offset: The offset field is the current estimated offset; the time difference between these peers in milliseconds.

jitter: The jitter field is the currently expected variation in delay between these peers in milliseconds. There is no jitter for a network with invariable latency. This is the time difference between 2 samples.

Most applications can tolerate an offset of a few milliseconds. But if the offset rises to beyond a second ten that could cause problems and might even affect application functionality. The higher offset value could indicate a network problem between the clients and ntp servers. Ideally, the values for delay, offset and jitter should be as small as possible.

I have been experimenting with NTP for a while now and let’s what the ntp log file holds today.

[root@linuxnix log]# tail /var/log/ntpd.log
19 Oct 19:40:51 ntpd[1885]: Listen normally on 3 eth1 192.168.87.144 UDP 123
19 Oct 19:40:51 ntpd[1885]: Listen normally on 4 lo ::1 UDP 123
19 Oct 19:40:51 ntpd[1885]: Listen normally on 5 eth1 fe80::20c:29ff:fe62:f03 UDP 123
19 Oct 19:40:51 ntpd[1885]: Listening on routing socket on fd #22 for interface updates
19 Oct 19:40:57 ntpd[1885]: 0.0.0.0 c016 06 restart
19 Oct 19:40:57 ntpd[1885]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
19 Oct 19:40:57 ntpd[1885]: 0.0.0.0 c011 01 freq_not_set
19 Oct 19:41:05 ntpd[1885]: 0.0.0.0 c61c 0c clock_step +1.055259 s
19 Oct 19:41:06 ntpd[1885]: 0.0.0.0 c614 04 freq_mode
19 Oct 19:41:07 ntpd[1885]: 0.0.0.0 c618 08 no_sys_peer

When NTP notices a change in clock and if it does step clock, with clock stepping ntp resets almost everything i.e server trust etc. The message is logged when the source selection doesn’t have any selectable source (for that short period, till it reselect sources again). After clock step, all sources need to collect new samples, trust them again and reselect them.

This concludes our ntp setup on Centos/RHEL. In a future article, we’ll explore ntpdate and ntptrace commands which are frequently used for debugging purposes.

Post Views: 19,380
The following two tabs change content below.

Sahil Suri

He started his career in IT in 2011 as a system administrator. He has since worked with HP-UX, Solaris and Linux operating systems along with exposure to high availability and virtualization solutions. He has a keen interest in shell, Python and Perl scripting and is learning the ropes on AWS cloud, DevOps tools, and methodologies. He enjoys sharing the knowledge he's gained over the years with the rest of the community.