Hello!
I'm running RouterOS 7.5 on a Chateau 5G (D53G-5HacD2HnD). RouterOS 7 includes the full NTP client & server built in, and doesn't need a separate package installed.
I am trying to use the Chateau as the NTP server for all the devices on its LAN, so that they all have a single consistent time source, rather than individual connections to potentially different internet time sources. For these devices my goal is to maximise relative consistency among the fleet, rather than absolute accuracy. Additionally, I want all devices on the LAN to have access to time synchronisation, but only a subset of them are actually permitted to send traffic to the WAN & internet. Therefore I want to use the Mikrotik's NTP server to provide time to the LAN-only devices.
The problem that I have is that RouterOS reports that its NTP client is working and synchronized, but the NTP clients getting time from the Chateau report that the NTP Server is not synchronized. This prevents the downstream clients from using the Chateau's time for synchronisation. Why could this be happening?
More details on configuration settings and evidence below.
The RouterOS NTP client is enabled, working and synchronized:
Code: Select all
[me@MYROUTER] > /system/ntp/client print enabled: yes mode: unicast servers: 0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org vrf: main freq-drift: 150.301 PPM status: synchronized synced-server: 1.pool.ntp.org synced-stratum: 2 system-offset: -346.674 ms [me@MYROUTER] /system/ntp/client/servers> printFlags: X - disabled; D - dynamic 0 address=0.pool.ntp.org resolved-address=27.124.125.251 min-poll=6 max-poll=10 iburst=yes auth-key=none 1 address=1.pool.ntp.org resolved-address=139.99.222.72 min-poll=6 max-poll=10 iburst=yes auth-key=none 2 address=2.pool.ntp.org resolved-address=203.29.242.183 min-poll=6 max-poll=10 iburst=yes auth-key=none 3 address=3.pool.ntp.org resolved-address=27.124.125.252 min-poll=6 max-poll=10 iburst=yes auth-key=none [me@MYROUTER] /system/ntp> monitor-peers type="ucast-client" address=139.99.222.72 refid="17.253.66.125" stratum=2 hpoll=9 ppoll=9 root-delay=0.335 ms root-disp=0.305 ms offset=-258.078 ms delay=96.48 ms disp=16.001 ms jitter=120.42 ms type="ucast-client" address=27.124.125.251 refid="162.159.200.123" stratum=4 hpoll=9 ppoll=9 root-delay=2.563 ms root-disp=0.625 ms offset=-269.07 ms delay=138.172 ms disp=41.043 ms jitter=176.6 ms type="ucast-client" address=203.29.242.183 refid="130.95.179.80" stratum=2 hpoll=9 ppoll=9 root-delay=1.831 ms root-disp=18.432 ms offset=-450.306 ms delay=138.533 ms disp=19.173 ms jitter=95.711 ms type="ucast-client" address=27.124.125.252 refid="202.70.69.81" stratum=2 hpoll=9 ppoll=9 root-delay=0.885 ms root-disp=0.366 ms offset=-540.282 ms delay=355.316 ms disp=15.846 ms jitter=182.991 msNTP Server is enabled for unicast (which is the only mode I want to use):
Code: Select all
[me@MYROUTER] > /system/ntp/server print enabled: yes broadcast: no multicast: no manycast: no broadcast-addresses: vrf: main use-local-clock: no local-clock-stratum: 5 auth-key: noneHowever my NTP clients on the LAN are reporting that although they can talk to the NTP server running on the Chateau, it is indicating that is not synchronized. Therefore my client devices are refusing to synchronise to the Chateau.
Here is the output from a Linux client device trying to synchronise to the NTP server at the Chateau's IP address:
Code: Select all
[pi@MYCLIENT:~ $ sudo ntpdate -uvdb 172.16.0.254 17 Oct 17:10:12 ntpdate[1730]: ntpdate 4.2.8p12@1.3728-o (1) Looking for host 172.16.0.254 and service ntp host found : 172.16.0.254 transmit(172.16.0.254) receive(172.16.0.254) transmit(172.16.0.254) receive(172.16.0.254) transmit(172.16.0.254) receive(172.16.0.254) transmit(172.16.0.254) receive(172.16.0.254) 172.16.0.254: Server dropped: leap not in sync server 172.16.0.254, port 123 stratum 3, precision -20, leap 11, trust 000 refid [139.99.222.72], root delay 0.091080, root dispersion 0.553360 transmitted 4, in filter 4 reference time: e6f797a8.b609c482 Mon, Oct 17 2022 16:58:16.711 originate timestamp: e6f79a9b.d38c64fd Mon, Oct 17 2022 17:10:51.826 transmit timestamp: e6f79a7b.2579c861 Mon, Oct 17 2022 17:10:19.146 filter delay: 0.02751 0.02744 0.02734 0.02747 0.00000 0.00000 0.00000 0.00000 filter offset: 32.67808 32.67838 32.67861 32.67889 0.000000 0.000000 0.000000 0.000000 delay 0.02734, dispersion 0.00023 offset 32.678617 17 Oct 17:10:19 ntpdate[1730]: no server suitable for synchronization foundSome relevant facts that I want to draw attention to. The ntpdate log shows both transmit(172.16.0.254) and receive(172.16.0.254) events, which indicates that the client device is getting a response packet back from the Chateau. The response from the server contains the correct stratum (3 - since it is synchronising to a stratum 2 pool.ntp.org server) and shows a sensible refid for the upstream pool.ntp.org server. But the leap value is "11". This is a bitmask of two bits; a value of 00 indicates full synchronisation, 01 and 10 have specific meanings concerned with leap second handling, and 11 means "unsynchronized".
Looking at some of my Windows devices on the LAN, and examining the status of the standard Windows NTP service w32time, shows similar status info. It displays the leap value bitmask's decimal value (3) rather than two separate bits (11):
Code: Select all
PS C:\Windows\system32> w32tm /query /statusLeap Indicator: 3(not synchronized)Stratum: 0 (unspecified)Precision: -23 (119.209ns per tick)Root Delay: 0.0775065sRoot Dispersion: 8.2703314sReferenceId: 0x00000000 (unspecified)Last Successful Sync Time: 17/10/2022 6:02:40 AMSource: 172.16.0.254Poll Interval: 10 (1024s)w32tm is able to successfully query the NTP server on the Chateau and report on the relative time difference, so this again reiterates that there does not seem to be any issue with routing or blocking NTP packets:
Code: Select all
PS C:\Windows\system32> w32tm /stripchart /computer:172.16.0.254Tracking 172.16.0.254 [172.16.0.254:123].The current time is 17/10/2022 5:52:03 PM.17:52:03, d:+00.0006544s o:-00.1444332s [ * ]17:52:05, d:+00.0006025s o:-00.1441264s [ * ]17:52:07, d:+00.0006019s o:-00.1438235s [ * ]17:52:09, d:+00.0005737s o:-00.1435123s [ * ]17:52:11, d:+00.0005563s o:-00.1432195s [ * ]Why would RouterOS's NTP client be showing "synchronized" while the server component is telling clients that it's not synchronized?
