1

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.

EDIT -1

We further found syslog for mentioning the choice of 169.254.1.51 despite higher stratum as below :-

 
Mar 24 05:01:01 Node ntpq: ============================================================================== Mar 24 05:01:01 Node ntpq: +10.241.34.2 10.240.33.1 4 u 693 1024 377 0.242 -251.08 10.473 Mar 24 05:01:01 Node ntpq: +10.241.34.3 10.241.34.2 5 u 46 64 377 6.675 -255.20 0.326 Mar 24 05:01:01 Node ntpq: +10.241.34.4 10.241.34.2 5 u 245 1024 377 0.312 -264.63 7.708 Mar 24 05:01:01 Node ntpq: *169.254.1.51 LOCAL(0) 11 u 12 64 377 0.143 80.034 2.248 Mar 24 05:01:01 Node ntpq: LOCAL(0) .LOCL. 10 l 10 16 377 0.000 0.000 0.001

  • Hi @ken-mollerup, I have seen you responding multiple times for NTP in past. It would be great, if you can answer to above as well. – ananTgarg Apr 3 '18 at 12:22
1

Look at this way: You have four servers:

  1. 10.241.34.2
  2. 10.241.34.3
  3. 10.241.34.4
  4. 169.254.1.51

Number two and three get their time from #1. But they are OK-ish low stratum, with 4 and 5. This is what I'd expect in an internal NTP server. They do report fairly close times, with similar offsets to your local clock, and their differences are within the jitter.

In addition you have 169.254.1.51, which is stratum 11. The stratum says something about how far removed from the time source (stratum 0) you are. Stratum 1 is connected to the time source, e.g. GPS or atomic clock. Stratum 2 is connected to stratum 1 and so on. You have three (in reality one, because #2 & #3 are referencing #1) servers that say hey, trust me, I'm four steps from the time source. They agree on the time.

Then you have one, that's half a second off these three, and says that it's eleven steps removed from a reliable clock. Of course NTP should trust the lower stratum NTP servers the most.

In addition you fudge the local clock to stratum 10. In effect you're saying that you trust the local clock more than your preferred NTP server. This will not work. The setup here is totally insane. In short. NTP is hierarchical and needs to be treated as such.

  1. Sync your 169.254.1.51 to an external pool. Pools are generally stratum 2-3, so it will end up as stratum 3-4. This is plenty good for most purposes.
  2. Set up three or more NTP servers, all getting time from one of the pools. You may peer them with each other, but to not make #2&3 get the time from #1.
  3. Make your clients use the three NTP servers you have set up.
  4. If you can not have three NTP servers, set up one, or use the pools directly. The pools will handle the load unless you have very many (think thousands) of clients.
  5. Do not fudge the local clock to stratum 10 - if it's not synchronized it should not be trusted. If you want time synchronization when no upstream source is available for some extent of time, set one of the servers local clock to stratum ten. This will make this the master if no upstreams are available.
  6. Two time sources is worse than one. If you have one, you follow it. If you have two, and they disagree, you don't know which one to follow. If you have three, and two agree, you know which one to follow. One other alternative is to define it as truechimer by appending the server line with true.

NTP Documentation contains some advice on configuring NTP. You should probably read it.

In addition, using 169.254.x.x in a network is a strange practice. I would recomend re-IPing that network to use a sane RFC1918-space. 169.254.0.0/16 is intended as a automatic link-local network, and should probably not be used in this manner.

  • Hi @vidarlo , Thank you very much for responding to it. I would like to provide you further information. – ananTgarg Apr 4 '18 at 5:12
  • In our system, we have master server 169.254.1.51, and a slave server 169.254.1.52, SO according to design slave always follow master as it is prefer. And the idea is to let master synch with external NTP server and slave sync with master. Now a issue happened that master server lost its connectivity with NTP server. Now master synchs with its local(stratum 10), and slave sync with remote server(stratum 4). This is fine as above but now a question which puts this analysis in a little doubt, that after 2 day the slave is again synching with Master despite master having higher stratum 11. – ananTgarg Apr 4 '18 at 5:20
  • Since it is not possible to add log in this comment, I am adding the logs in EDIT1 of question. – ananTgarg Apr 4 '18 at 5:25
  • I'd say start over with your setup, and read the suggestions in the NTP documentation, and for instance this advice from Redhat. – vidarlo Apr 4 '18 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.