Preferred NTP server was rejected despite having better offset and jitter

Question

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.

Can you add the output from `ntpq pcrv` please. Your timing setup looks a bit of a mess to be honest. The server you want to 'prefer' is using its local clock for a starter! — user3788685, Mar 28 '18 at 20:05
Hi @user3788685 , Thank you for your response. Unfortunately we do not have the output of above command from the system and we do not have access to the setup, so we cannot run the command now. Is it possible to check something from available logs or some design behavior. — ananTgarg, Apr 02 '18 at 06:38
>> The server you want to 'prefer' is using its local clock for a starter We checked the reason for it and found that the prefer server is having network issue and that is why prefer server is not synching to external NTP server. — ananTgarg, Apr 02 '18 at 07:13

Preferred NTP server was rejected despite having better offset and jitter

0 Answers0