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 220.127.116.11 2 u 68 64 16 407.070 348.327 258.477 -ntp.gnc.am 18.104.22.168 2 u 4 64 7 560.334 672.630 406.733 +ntp.hoster.kg 22.214.171.124 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 126.96.36.199 2 u 51 64 1 573.896 336.766 69.322 *ntp.gnc.am 188.8.131.52 2 u 47 64 1 539.843 409.441 100.579 +ntp.hoster.kg 184.108.40.206 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: Listen normally on 3 eth1 192.168.87.144 UDP 123 19 Oct 19:40:51 ntpd: Listen normally on 4 lo ::1 UDP 123 19 Oct 19:40:51 ntpd: Listen normally on 5 eth1 fe80::20c:29ff:fe62:f03 UDP 123 19 Oct 19:40:51 ntpd: Listening on routing socket on fd #22 for interface updates 19 Oct 19:40:57 ntpd: 0.0.0.0 c016 06 restart 19 Oct 19:40:57 ntpd: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 19 Oct 19:40:57 ntpd: 0.0.0.0 c011 01 freq_not_set 19 Oct 19:41:05 ntpd: 0.0.0.0 c61c 0c clock_step +1.055259 s 19 Oct 19:41:06 ntpd: 0.0.0.0 c614 04 freq_mode 19 Oct 19:41:07 ntpd: 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.
Latest posts by Sahil Suri (see all)
- Setting up chrooted ssh jails in Linux - October 8, 2019
- How To exclude copying of specific directories in Linux using cp/scp/rsync - October 7, 2019
- Docker container ports explained - September 27, 2019
- Docker Volumes explained - September 25, 2019
- Docker networking commands explained - September 24, 2019