Differences

This shows you the differences between two versions of the page.

--- eduardo:linux:ntpd [2014/11/08 15:56] – created eduardo
+++ eduardo:linux:ntpd [2024/02/23 08:20] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== NTPD ======
+NTP servers communicate over port 123 UDP and unlike most UDP protocols the source port is NOT a high port, but uses 123 as well.  The firewall must be configured to allow UDP on both source and destination ports 123 between your new NTP server and the Stratum 1 server.
+===== iptables =====
+Using iptables
+<code>
+[bash]# iptables -I INPUT -p udp --dport 123 -j ACCEPT
+[bash]# service iptables save
+</code>
+===== firewallld =====
+Using firewallld. Assuming default zone is public.
+<code>
+[bash]# sudo firewall-cmd --zone=public --add-service=ntp
+[bash]# sudo firewall-cmd --reload
+</code>
+To verify the rules.
+<code>
+[bash]# firewall-cmd --list-all
+public (default, active)
+  interfaces: eth0
+  sources:
+  services: dhcpv6-client ntp ssh
+  ports:
+  masquerade: no
+  forward-ports:
+  icmp-blocks:
+  rich rules:
+</code>
+Now that we have our firewall rules in place to allow NTP synchronization, let's get the service installed and started.
+Most modern Linux/UNIX distributions come with NTP already installed. For Red Hat based distros you can install the NTP package with yum
+<code>
+[bash]# yum install ntp
+</code>
+The main configuration file for NTP in Red Hat based linux based systems is ntp.conf located in the /etc directory. For this first step we will open that file in our favorite editor and place the servers we want to use in the following format. The following assume our external clock source server is 10.1.19.12. The first two lines were commented out as we are using an external clock source instead of local clock.
+<code>
+# server 127.127.1.0  # local clock
+# fudge 127.127.1.0 stratum 10
+server  10.1.19.12
+</code>
+Now we have to restrict the access these time servers will have on our system.  In the example below we are telling NTP that these servers are not allowed to modify run-time configuration or query our system. The specified mask below is limiting the access to a single IP, or single host subnet.
+<code>
+restrict 10.1.19.12 mask 255.255.255.255 nomodify notrap noquery
+</code>
+Now since we are setting up a server to "serve" time to other clients we have to tell it from which networks to allow NTP requests. We use the same basic restrict statement as above, but this time you will notice the noquery option is removed allowing said network to query this server. The following example allows everyone within the 10.64.64.0/24 network to query the server.
+<code>
+restrict 10.64.64.0 mask 255.255.255.0 nomodify notrap
+</code>
+As with most services localhost gets full access.  For this we use the same restrict statement but with no options.
+<code>
+restrict  127.0.0.1
+</code>
+Restart NTPD
+<code>
+[bash]#  service ntpd restart
+</code>
+In RH 7.X. Restart NTPD
+<code>
+[bash]#  systemctl start ntpd.service
+</code>
+That's it, we have now configured our NTP server to pull time synchronization from stratum 1 servers, and accept time synchronization requests from computers on our network.  Now we have to start the service and make sure the service starts at boot. Before we go crazy let's make sure everything is working as expected and also run an initial update.
+First, let's run an initial update.
+<code>
+[bash]# ntpq -p 10.1.19.12
+     remote           refid      st t when poll reach   delay   offset  jitter
+==============================================================================
++padhux31.in.rea 223.255.185.2    2 u   39  128  356    0.120   -0.329   1.510
+ tmhhux50.in.rea 10.1.19.12       3 u  399  512  166  114.090   -0.349   8.670
+ tmhhux51.in.rea 10.1.19.12       3 u  419 1024  356  113.770   -1.400  15.980
+*223.255.185.2   .MRS.            1 u  904 1024  325  121.200   -2.306   3.520
+ padhux04.in.rea 133.100.9.2      3 -  61d 1024    0    0.120   23.153 16000.0
+</code>
+You should now set the runlevels required for the ntpd service, then restart it.
+<code>
+[bash]# chkconfig --level 2345 ntpd on
+[bash]# /etc/init.d/ntpd restart
+Or in RH7.x
+[bash]# systemctl enable ntpd.service
+</code>
+You can check which runlevels the service will be active with the following command.
+<code>
+[bash]# chkconfig --list ntpd
+Or in RH7.x
+[bash]# systemctl list-unit-files | grep ntpd
+</code>
+To see if the service started successfully, you should check the system log file.
+<code>
+[bash]# grep ntpd /var/log/messages
+Nov  8 22:52:48 gcc-rhel ntpd[15652]: ntpd 4.2.2p1@1.1570-o Mon May 30 15:43:16 UTC 2011 (1)
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: precision = 1.000 usec
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: Listening on interface wildcard, 0.0.0.0#123 Disabled
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: Listening on interface lo, 127.0.0.1#123 Enabled
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: Listening on interface eth0, 10.64.64.6#123 Enabled
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: kernel time sync status 0040
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: getaddrinfo: "::1" invalid host address, ignored
+Nov  8 22:52:48 gcc-rhel ntpd[15653]: frequency initialized 71.419 PPM from /var/lib/ntp/drift
+Nov  8 22:57:08 gcc-rhel ntpd[15653]: synchronized to 10.1.19.12, stratum 2
+Nov  8 22:57:08 gcc-rhel ntpd[15653]: kernel time sync enabled 0001
+</code>
+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.
+<code>
+[bash]# ntpq -pn
+     remote           refid      st t when poll reach   delay   offset  jitter
+==============================================================================
+*10.1.19.12      223.255.185.2    2 u   14  256  377  115.690   -2.822   0.922
+</code>
+<note important>We need to wait until ntpd sync with the clock source first before it will start working. This can take up to 5 mins. Monitor /var/log/messages for the synchronized messages</note>
+===== Offset =====
+If the offset is too high, NTP won't sync. We can do manual sync (STEP) by running. E.g. offset below is 26s
+<code>
+     remote           refid      st t when poll reach   delay   offset  jitter
+==============================================================================
+.84.191.10   10.100.1.21      6 u    5   64    3    0.313  -26321.   0.827
+</code>
+<code>
+ntpdate -u <ntp IP>
+</code>
+===== Reachability =====
+Start your NTP daemon. Curious to see how well it's syncing up, you monitor the output of ntpq -pn and watch the reachability statistics in the reach field climb towards the mysterious upper bound of 377. At last, the system has reached that exalted state, and all is well with the world.
+<code>
+[bash]# ntpq -pn
+     remote           refid      st t when poll reach   delay   offset  jitter
+==============================================================================
+*10.1.19.12      223.255.185.2    2 u   14  256  377  115.690   -2.822   0.922
+</code>
+Each remote server or peer is assigned its own buffer by ntpd. This buffer represents the status of the last eight NTP transactions between the NTP daemon and a given remote time server. Each bit is a boolean value, where a 1 indicates a successful transaction and a 0 indicates a failure. Each time a new packet is sent, the entire eight-bit register is shifted one bit left as the newest bit enters from the right.
+The net result is that dropped packets can be tracked over eight poll intervals before falling off the end of the register to make room for new data. This recycling of space in the register is why it's called a circular buffer, but it may make more sense to think of it in linear terms, as a steady, leftward march--eight small steps, and then the bit ends up wherever bits go when they die.
+For reasons that seemed good to the developers, this register is displayed to the user in octal values instead of binary, decimal or even hex. The maximum value of an eight-bit binary number is 11111111, which is 377 in octal, 255 in decimal and 0xFF in hex.
+So why does the value of the reach field drop when packets are being successfully sent and received? For those of you who dream in octals, this next part may seem obvious. For ordinary mortals, it requires closer scrutiny.
+The answer is that the lower numerical values are caused by the left-shifting of the reachability register. Remember, the buffer is not a metric, it is a FIFO log. So, if you have received the last eight NTP packets successfully, the log contains all 1s and the reach field contains the octal value of 377.
+Let's assume that on the next update, a packet is dropped. Because NTP is a UDP-based protocol with no delivery guarantees, this is not necessarily a cause for alarm. But the NTP daemon dutifully logs the failure in the circular buffer and waits for the next poll period. The log now contains 11111110 and a reach field value of 376.
+If the next seven polls are successful, seven 1s are added from the right-hand side of the register, pushing the 0 representing the dropped packet further towards the left (and digital oblivion). Listing 4 shows the progression of a single dropped packet through the reachability register.
+<code>
+ Buffer     Octal    Decimal
+--------    -----    -------
+11111110     376       254
+11111101     375       253
+11111011     373       251
+11110111     367       247
+11101111     357       239
+11011111     337       223
+10111111     277       191
+01111111     177       127
+11111111     377       255
+</code>
+As you can see, the 0 representing the dropped packet is moved one bit to the left every time the daemon polls its server. The numerical value assigned to each bit is higher on the left than on the right. In the binary system, the leftmost digit holds a value of 128, while the rightmost digit represents a value of 1. So, as the zero moves leftwards, it actually produces a lower numerical value, despite the fact that its distance from the right-hand side of the register represents an increase in the time since the packet was dropped.
+If the zero falls off the end of the register, and no other packets have been dropped, the value of the reach field jumps back to 377 with no intervening steps. This can be very confusing if you insist on viewing the numbers as a connection metric rather than as a history log.