Ntp causing problems

Question

I have a FreeIPA server running on Centos 6 and one of its functions is to provide time sync to client hosts. NTP is version 4.2.6

The problem is that its own NTP synchronisation is nor working properly & I can't see why. This is then affecting the Kerberos/authentication functions.

The FreeIPA server cannot directly get to the internet so it needs to use another server that can see the internet.

Here is an nptq listing from the "master" time server whose IP address is 10.20.1.23.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*46.101.52.119   81.174.136.35    2 u  111  128  377   10.234    0.865   3.491
+51.141.4.8      85.199.214.102   2 u  121  128  377   14.806   -0.365   2.858
+178.62.16.103   195.66.241.3     2 u  117  128  377   10.677    0.816   1.931
+129.250.35.250  249.224.99.213   2 u  100  128  377   14.064   -1.678   1.525

All pretty standard stuff. 46.101.52.119 is being used as reference

Here is the output from another client using that server for time sync

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.20.1.23       46.101.52.119    3 u  230  256  377    0.439  1095.65  34.637
 127.127.1.0     .LOCL.           5 l  49m   64    0    0.000    0.000   0.000

This is fine telling me 10.20.1.23 is using 46.101.52.119 as its ref

But when I go to me FreeIPA server I get

# ntpq -pn
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.20.1.23       LOCAL(0)         6 u   97  128  377   32.193  92334.0  17.646

The refid is different and it tells me we have about a minute & a half offset. In fact I set the clocks within a second by hand but now it's being pulled off by ntpd.

Answer 1

Also see: Why is NTP syncing to LOCAL rather than remote server?

What seems to be going on is that your local clock is running way too fast in relation to the time source that it's trying to sync against. As a result it trashes the synchronization source and goes with what it thinks is the best answer, which is it's own local kernel timesource. There are a couple of things you can do to help alleviate this condition and try getting your local clock into better shape.

First, to alleviate the issue, you can set the local clock to a higher stratum than your synchronization sources. An example in your ntp.conf file would be:

server 127.0.0.1
fudge 127.0.0.1 stratum 16   ## or some value greater than it's synchronization peer

This will make it a less-desirable source when NTP starts selection of peers for synchronization.

Next, if your local clock is really out of whack, you can adjust it using adjtimex. BE CAREFUL, you are playing with the hardware clock at this point. An example would look something like:

# adjtimex -p         ## List out how the clock is currently running...
     mode: 0
   offset: 0
frequency: 0
 maxerror: 0
 esterror: 0
   status: 64
time_constant: 4
precision: 1
tolerance: 32768000
     tick: 9900
 raw time:  1272299204s 17444us = 1272299204.017444
return value = 5

And adjust the value of the 'tick' field:

adjtimex -t 9800

Restart ntpd and see how it behaves. If it makes the jitter more acceptable, then leave it at that, or adjust it again, if necessary. NTP can be somewhat obscure and I hope I've helped things, but if you need more information, I'd trust the source at http://support.ntp.org

References

http://support.ntp.org/bin/view/Support/TroubleshootingNTP

http://log.or.cz/?p=80