We have a NTP client configured on one of our system. The client has a set of servers available with whom it can synch with.
However the preferred server that we chose is our internal master server with IP 169.254.1.51.
The contents of ntp.conf for same are below :-
# --- CLIENT NETWORK -------
# --- USER SETTINGS BEGIN ---
server 10.241.34.2 iburst
server 10.241.34.3 iburst
server 10.241.34.4 iburst
restrict 10.241.34.2 mask 255.255.255.255 nomodify notrap noquery
restrict 10.241.34.3 mask 255.255.255.255 nomodify notrap noquery
restrict 10.241.34.4 mask 255.255.255.255 nomodify notrap noquery
# --- USER SETTINGS END ---
# --- NTP MULTICASTCLIENT ---
restrict 169.254.0.0 mask 255.255.0.0 nomodify notrap # internal network
# --- INTERNAL TIMESERVERS BEGIN-----
server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #Internal master Server
# --- GENERAL CONFIGURATION ---
server 127.127.1.0 iburst minpoll 4 # local clock
fudge 127.127.1.0 stratum 10
tinker step 0
The above is for the configuration part. However when we check the syslog after configuration and restarting system, We found that client is synchronizing with external server instead of prefer server as captured in ntpq output in syslog
Mar 22 05:52:48 Node ntpcheck: remote refid st t when poll reach delay offset jitter
Mar 22 05:52:48 Node ntpcheck: ==============================================================================
Mar 22 05:52:48 Node ntpcheck: *10.241.34.2 10.240.33.1 4 u 2 64 1 0.192 -519.50 5.769
Mar 22 05:52:48 Node ntpcheck: 10.241.34.3 10.241.34.2 5 u 1 64 1 0.172 -523.79 8.912
Mar 22 05:52:48 Node ntpcheck: 10.241.34.4 10.241.34.2 5 u 2 64 1 0.207 -520.73 8.082
Mar 22 05:52:48 Node ntpcheck: 169.254.1.51 LOCAL(0) 11 u 1 16 1 0.113 -0.043 2.099
Mar 22 05:52:48 Node ntpcheck: 127.127.1.0 .LOCL. 10 l 14 16 1 0.000 0.000 0.001}
Further the below message message was continuously flooding in syslog
Mar 22 06:51:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:51:27 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:51:45 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:52:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:52:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:52:35 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:52:51 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:06 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:53:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:23 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:53:38 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:54:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:54:29 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:54:47 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:02 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:55:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:21 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:55:35 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:56:10 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:56:28 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:56:46 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:57:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:57:21 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:57:38 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:57:54 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:58:09 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:58:24 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:58:42 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:58:59 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:59:15 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:59:30 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:59:46 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 07:00:02 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 07:00:17 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
We tried to check on NTP forums and identified that it uses below parameter in defining the server to be prefer synching with (Reference:- https://www.eecis.udel.edu/~mills/ntp/html/warp.html) :-
- First level of rejection happens based on offset and delay.
- Then after rejecting the pool, the survivors are passed to clock clustering algorithm.
- The clustering algorithm depends on jitter to decide.
- The remaining all servers are selectable survivors, any one of them can be choosen.
- Now the role of prefer keyword come into play, and all selectable are checked and prefer one is choosen.
- If the survivor is not present, then migration rule decide the peer.
However in the ntpq output the prefer server has better offset and jitter, even then it is not chosen.
Is it possible to identify that on what basis it is rejecting preferred server in this case.