1

I have 2 NTP servers. One synchronized directly with a GPS clock (I will call this server 185), so st 0. Then I have a second one (Let's call it 186) that should synchronize with the 185 since it is st 1 but instead it synchronizes with LOCAL.

[root@185 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(3)      .GPS.           0 l    6   64    7    0.000    5.902   2.454
 LOCAL(0)        .LOCL.          10 l    -   64    0    0.000    0.000   0.000


[root@186 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 GENERIC(3)      .GPS.           0 l    -   64    0    0.000    0.000   0.000
 192.168.61.185  .GPS.           1 u   52   64    1    0.238    0.036   0.000
*LOCAL(0)        .LOCL.          10 l   51   64    1    0.000    0.000   0.000

Configuration is quite straight forward since this is one of the first tests we do. In addition, I have the parameter tinker panic 0 set in both ntp.conf.

Do you have any idea why 186 does not choose 185?

Thanks in advance!

EDIT : To show that 186 can reach 185.

***EDIT : more info (date is 1 Jan because the GPS is simulated) ***

[root@ntp1 ~]# ntpdate -d 192.168.xx.185
 1 Jan 10:08:16 ntpdate[17348]: ntpdate 4.2.6p5@1.2349-o Fri Dec 18 13:55:10 UTC 2020 (1)
Looking for host 192.168.xx.185 and service ntp
host found : 192.168.xx.185
transmit(192.168.xx.185)
receive(192.168.xx.185)
transmit(192.168.xx.185)
receive(192.168.xx.185)
transmit(192.168.xx.185)
receive(192.168.xx.185)
transmit(192.168.xx.185)
receive(192.168.xx.185)
server 192.168.xx.185, port 123
stratum 1, precision -23, leap 00, trust 000
refid [GPS], delay 0.02576, dispersion 0.00000
transmitted 4, in filter 4
reference time:    c39e6ff9.17cf49c0  Thu, Jan  1 2004 10:07:53.093
originate timestamp: c39e7011.1621002b  Thu, Jan  1 2004 10:08:17.086
transmit timestamp:  c39e7011.16146846  Thu, Jan  1 2004 10:08:17.086
filter delay:  0.02586  0.02576  0.02576  0.02583
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000067 0.000094 0.000098 0.000065
         0.000000 0.000000 0.000000 0.000000
delay 0.02576, dispersion 0.00000
offset 0.000094
Paul Gear
  • 4,367
  • 19
  • 38
Moncloa
  • 11
  • 3
  • 1
    REACH is 0. That indicates that you can't reach that NTP server. – vidarlo Dec 21 '22 at 09:36
  • Actually it becomes 0 after a while, but after the restart reach isn't 0. `192.168.xx.185 LOCAL(0) 11 u 25 64 1 0.180 0.010 0.000` – Moncloa Dec 21 '22 at 10:12
  • 3
    [Edit] your post to include the output of `ntpdate -d 192.168.xx.185`. And stop redacting RFC1918-addresses. It just looks silly. – vidarlo Dec 21 '22 at 10:25
  • I do redact RFC1918-addresses because world is small, not for security issues... :) – Moncloa Dec 21 '22 at 10:31
  • 3
    Stop doing it anyway. It doesn't reveal anything about you. – vidarlo Dec 21 '22 at 11:13
  • Please include your ntpd configuration as well - using `grep '^[^#]' /etc/ntp.conf` is recommended to make it compact. – Paul Gear Dec 21 '22 at 23:04
  • 1
    Also, as @vidarlo requested, please don't redact addresses. It just makes it harder for others to help you. – Paul Gear Dec 21 '22 at 23:04
  • 3
    And most importantly, please don't use the LOCAL driver. It has been deprecated for many years. Start with your distribution's default `/etc/ntp.conf` template (CentOS, Debian, & Ubuntu all have very sane defaults), and only change the things necessary for it to work in your environment. – Paul Gear Dec 21 '22 at 23:05

0 Answers0