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:
[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> print
Flags: 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 ms
NTP Server is enabled for unicast (which is the only mode I want to use):
[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: none
However 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:
[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 found
Some 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):
PS C:\Windows\system32> w32tm /query /status
Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0775065s
Root Dispersion: 8.2703314s
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: 17/10/2022 6:02:40 AM
Source: 172.16.0.254
Poll 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:
PS C:\Windows\system32> w32tm /stripchart /computer:172.16.0.254
Tracking 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?