Mikrotik as NTP server, reachable but does not sync

RouterOS General
1

I’ve set up the hex as an NTP server for my network along with the FW rule required, code below

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
add action=accept chain=input dst-port=123 in-interface=lab protocol=udp
add action=accept chain=input dst-port=123 in-interface=mgmt protocol=udp
/system ntp server
set broadcast=yes broadcast-addresses=192.168.68.255,192.168.77.255 enabled=yes

I got VMs that attempt to perform a sync but failed to do so. Checking the connection to the Mikrotik works though

# systemctl is-active chronyd
active
# chronyc tracking
Reference ID    : 00000000 ()
Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.000000007 seconds slow of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 389.664 ppm fast
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.000000000 seconds
Root dispersion : 1.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised
# chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? mikrotik.                     0   7     0     -     +0ns[   +0ns] +/-    0ns
# nc -zvu mikrotik 123
Connection to mikrotik (192.168.68.1) 123 port [udp/ntp] succeeded!

This has been boggling me a bit as to why it can’t sync in spite of a successful connection test. If i ‘forcibly’ sync it, it says it can’t regardless if IP is used.

# chronyd -q 'server mikrotik iburst'
2023-03-12T13:54:51Z chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2023-03-12T13:54:51Z Could not open command socket on [::1]:323
2023-03-12T13:54:51Z Initial frequency 389.664 ppm
2023-03-12T13:54:59Z No suitable source for synchronisation
2023-03-12T13:54:59Z chronyd exiting
# chronyd -q 'server 192.168.68.1 iburst'
2023-03-12T13:56:31Z chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2023-03-12T13:56:31Z Could not open command socket on [::1]:323
2023-03-12T13:56:31Z Initial frequency 389.664 ppm
2023-03-12T13:56:40Z No suitable source for synchronisation
2023-03-12T13:56:40Z chronyd exiting
2

For NTP server on ROS to do whst it’s supposed to do also NTP client on same device has to be up&running. So is NTP client state “synchronized”?

/system ntp client print

If client is not synchronized, then server will not return meaningfull sync data.

3

A question you have to ask because the poster assumed he knew where the problem lies and did not provide the full config but only parts of the config…
Therefore its not clear if both server and client are configured…
Also I use NTP server settings without stating any broadcast entry??

4

Mikrotik is sync’d

> /system/ntp/client/print
         enabled: yes
            mode: unicast
         servers: 0.asia.pool.ntp.org,1.asia.pool.ntp.org,2.asia.pool.ntp.org,3.asia.pool.ntp.org
             vrf: main
      freq-drift: 0 PPM
          status: synchronized
   synced-server: 3.asia.pool.ntp.org
  synced-stratum: 2
   system-offset: 495.198 ms
5

This is very strange… I didn’t change any config all I did was

> /system/ntp/server/set enabled=no
> /system/ntp/server/set enabled=yes

And now time sync is working. I’m pretty sure prior to this ‘restart’, ntp server is already set to enabled=yes

6

Very understandable spyghost, I entered the thread, calm descended and problems magically got solved.
Now only if mikrotik could weave a little magic AND PROVIDE

Zerotrust Cloudflare tunnel as an options package for all MT devices!!!

7

@spyghost: when client status says “freq-drift: 0 PPM”, then either device has a perfect oscillator (highly unlikely) or NTP client didn’t do the synchronization properly yet … it takes hours if not days for NTP client to settle to usable accuracy after it’s configured from scratch (frequency drift is later stored to non-volatile storage so next time service starts, it can initialize to last good state). The “system-offset: 495.198 ms” is indicating that it’s the later (offset of roughly 1/2 second is excessive in NTP world). So I’d say that letting NTP client on ROS to do it’s magic for a day actually solved the issue. Now, it might have a bug or two and having to disable/enable server is one of those.
My experience with NTP server on 6.49.7 is that even if it synchronizes properly, it’s not accepted by NTP client on ROS 7.8. ROS 7.8 server is fine for other 7.8 clients though.

@anav: you’re risking of getting a special badge: “zerotrust spammer of the month” :wink:

8

There are two truths in life!
Ukraine must defeat Muscovy
and
MT must provide zerotrust cloudflare option.

9

I bet you still haven’t tried it in a container. So just the video was a seller for you?

Does Nova Scotia have any bridges to no-where like Alaska does? I can sell you a bridge to zerotrust if not. :slight_smile: