NTP still not working

Networking
1

G’day all,

Out of the box NTP does not seem to work correctly.

we have:

    [root@cf-fw ~]# cat /etc/ntp.conf
    disable monitor
    restrict default nomodify noquery
    restrict 127.0.0.1
    server  127.127.1.0 prefer
    fudge   127.127.1.0 stratum 10
    driftfile /etc/ntp/drift

If you want NTP to work correctly you need something like:

    [root@cf-fw ~]# cat /etc/ntp.conf
    disable monitor
    restrict default nomodify
    pool 0.uk.pool.ntp.org
    pool 1.uk.pool.ntp.org
    pool 2.uk.pool.ntp.org
    pool 3.uk.pool.ntp.org
    
    fudge   127.127.1.0 stratum 10
    driftfile /etc/ntp/drift

I have removed

restrict 127.0.0.1
server  127.127.1.0 prefer

and added some pools

If you don’t make changed to ntp.conf you don’t get proper ntp synchronisation

Before the change on IPFire

[root@cf-fw ~]# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *LOCAL(0)        .LOCL.          10 l   11   64  377    0.000   +0.000   0.000

Note that ntp is using LOCAL source, so probably fighting the 1 hourly sync.

And a host on green:

    root@nostromo:/shares/doc# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *cf-fw.coastfm.c LOCAL(0)        11 u  308 1024  377    0.212  -118.55 118.822

Note the LOCAL(0) on nostromo, I believe ntp is clever enough to say 'hey, our upstream server is using local, I have a local too! I will use my local)

Making the change, we now have:

    [root@cf-fw ~]# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     0.uk.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
     1.uk.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
     2.uk.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
     3.uk.pool.ntp.o .POOL.          16 p    -   64    0    0.000   +0.000   0.000
    +85.199.214.100  .GPS.            1 u   60   64  377   12.028   -6.732   4.894
    #time.cloudflare 10.21.8.19       3 u    1  128  377   10.509  -25.550  18.986
    -time.netweaver. 85.199.214.98    2 u  128  128  377   10.988   -7.090  10.747
    -ns3.turbodns.co 85.199.214.99    2 u   59  128  377   15.830  -13.917  13.064
    -183.ip-51-89-15 225.254.30.190   4 u    2  128  377   10.232   -8.263   9.131
    +time.cloudflare 10.21.8.19       3 u  118  128  377   10.167   -5.649  12.197
    #ntp3.wirehive.n 81.187.26.174    2 u   73  128  377   11.812  -23.923  17.777
    *85.199.214.98   .GPS.            1 u    3   64  377   12.389   -0.610   2.689
    -ns1.luns.net.uk 157.44.176.4     2 u   67  128  377   16.633   +0.325  14.474
    #x.ns.gin.ntt.ne 249.224.99.213   2 u   60  128  377   10.737   -1.304  13.492
    -ntp.uk.eria.one 85.199.214.102   2 u   59  128  377   11.196   -8.670   9.665
    -devrandom.pl    85.199.214.101   2 u   65  128  377   11.445   -1.382  13.179
    -51.155.16.62 (5 .GPS.            1 u   38  128  377   33.163   +0.470  14.223

and on a green host:

    root@nostromo:/shares/doc# ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *cf-fw.coastfm.c 85.199.214.98    2 u   65   64  377    0.188   -8.333   3.349

Woot! much better, no drift and everything in sync. I am sure I have posted this before, but could not find it.

In the WUI, make ntp synchronisation manual, dont need that any more.
And having an 3 or more upstream servers is much better, 2 is worse than 1 I think, with 2 ntp does not know who is accurate.

1 Like
2

This is what I had found…

EDIT: for code blocks and for log blocks add three back ticks ``` before the code and three back ticks ``` after the code.

3

/shrug dunno

All I know is that out of the box, ntp never seemed to work, hosts behind the firewall were always using LOCAL(0) IE their own time source and our clocks drifted all over the place. Once I made the changes and restarted ntp, everything was in sync.
I am not sure the
restrict 127.0.0.1
has to be removed, but I am pretty sure
server 127.127.1.0 prefer
does. This causes IPFire to never use external sources.

I am by no way an ntp expert but I have debugged a lot ntp issues over the years.

I set the host name ntp to be IPfire and the /etc/ntp.conf on a green node looks like

root@nostromo:~# cat /etc/ntp.conf|grep -v "^#"|grep -v "^ *$"
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery
server ntp

I added the server ntp line.

There may be other solutions and maybe it does work out of the box, but it didn’t seem to be correct to me.
I need to keep clocks in sync and 1 hour updates were not cutting it either. We had drift over the hour.
This way we have proper ntp time sync.
(Mind you we had a UPS plugged into a UPS in error! That was not helping the time drift on one server!)
(We are a radio station so we need accurate timing for events to fire across nodes!)

4

Hi Mike
FYI: I reported bug 12518 back in Oct 2020 since ntpq -p was not working. I looked a Debian sources and found “restrict 127.0.0.1” was needed in the ntpd.conf

https://bugzilla.ipfire.org/show_bug.cgi?id=12518

1 Like
5

NTP issues are fixed in IPFire 2.27 - Core Update 169 released.

see:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2234e8aacac2e0d0b06dac4513585c15c2b3b440

1 Like