Hello!
According to RFC5905: “Primary servers are assigned stratum one; secondary servers at each lower level are assigned stratum numbers one greater than the preceding level.”
My RouterOS 6.36 ntpd announces it is at stratum 0. I have a couple of devices that complain stratum must be in range 1-15 and can’t synchronize. So would You please make startum configurable (preferred) or make it in range 1-15?
Kind regards,
Boris
It is not good to make it configurable.
It should have the correct value depending on the stratum of the reference it uses.
How does your router obtain time?
(locally connected GPS receiver, using other NTP servers, or using the “cloud time” feature)
My router obtain time via external NTP servers.
@borisk:
That top level (stratum 0) they talk about are the atomic clocks used as global references, like those at NIST, and the GPS reference clocks.
Unless you have a cesium clock at home, your time source is NOT stratum 0, and unless you have a GPS PPS synchronized time server, not even stratum 1. So those complains are right.
Since Mikrotik routers do not support PPS for time synchronization, it seems correct to assume they are at most stratum 4, unless they are synchronized to a lower stratum NTP server, when the MT will automatically get stratum N+1, where N is the uplink time source stratum - so you will get stratum 2 in the best case for your MT router.
Even more, that stratum 4 is actually faked if you run off the local clock, but was put in place so that the MT can be used as local network time source for windows machines, which only accept time sources with stratum less than 5.
I have checked the behavior of the NTP server on recent NTP server packages on MT hardware, and all of them onnor the stratum conventions properly.
Dear all!
Thanks for clarification. Maybe I really missed something in NTP, but to facts:
So, when I point another devices to RouterOS as NTP server, it returns:
%Aug 07 18:12:58 2016 NTP: xmit packet to 10.255.255.254
%Aug 07 18:12:58 2016 leap 0, mode 3, version 4, stratum 3, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.000ms, refid 95.104.192.10
%Aug 07 18:12:58 2016 ref db51f82f.613543ae (Sun Aug 7 18:10:55.379 2016)
%Aug 07 18:12:58 2016 org 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 rec 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 xmt db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 NTP: receive packet from 10.255.255.254
%Aug 07 18:12:58 2016 leap 3, mode 4, version 4, stratum 0, ppoll 6
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.092ms, refid 73.78.73.84
%Aug 07 18:12:58 2016 ref 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
%Aug 07 18:12:58 2016 org db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 rec db51b22c.a98d5222 (Sun Aug 7 13:12:12.662 2016)
%Aug 07 18:12:58 2016 xmt db51b22c.aa27766d (Sun Aug 7 13:12:12.664 2016)
stratum error <1-15> !
Is this wrong? I think - yes. Have I misunderstood something with NTP? May be yes 
But I can’t synchronize with ROS NTP server. What to do? Please clarify.
Kind regards,
Boris
This seams correct. Stratum 3 is as it should be.
Now this is certainly wrong.
First of all there is this ref 00000000.00000000 which is invalid. This have to be a time stamp when the server last time set its clock.
Since it never happened, this whole information is invalid.
This seams correct. Stratum 3 is as it should be.
I changed thread title to “bug”
@docmarius:
And yes, ROS is synchronized to external NTP:
[boris@MikroTik] /system clock> print
time: 18:35:50
date: aug/07/2016
time-zone-autodetect: yes
time-zone-name: Asia/Yekaterinburg
gmt-offset: +05:00
dst-active: no
[boris@MikroTik] /system clock> /system ntp client print
enabled: yes
mode: unicast
primary-ntp: 95.104.192.10
secondary-ntp: 93.180.6.3
dynamic-servers:
status: started
Now if I check the specs on the ntp, I think it may be correct somehow…
Let me explain:
%Aug 07 18:12:58 2016 rootdelay 0.000ms, dispersion 0.092ms, refid 73.78.73.84
%Aug 07 18:12:58 2016 ref 00000000.00000000 (Thu Jan 1 00:00:00.000 1970)
Here we see that the MT uses server 73.78.73.84 as uplink, but has never set its clock (ref is 0).
So the router’s system time is invalid from NTP point of view.
%Aug 07 18:12:58 2016 org db51f8aa.119c38b0 (Sun Aug 7 18:12:58.068 2016)
%Aug 07 18:12:58 2016 rec db51b22c.a98d5222 (Sun Aug 7 13:12:12.662 2016)
%Aug 07 18:12:58 2016 xmt db51b22c.aa27766d (Sun Aug 7 13:12:12.664 2016)
And here we see the timestamp dialog, which seems valid.
And now let’s see the result:
%Aug 07 18:12:58 2016 leap 3, mode 4, version 4, stratum 0, ppoll 6
So what you are basically getting is a response that your time server is not synchronized. The question is: is your upper NTP layer working correctly?
It seems it is just set to synchronize, but is not actually synchronized when the problem occurs.
BTW, server 73.78.73.84 is not in your server list. Where does this come from?
It seems your client isn’t working, which makes the server behavior correct.
It should look like:
[admin@YO2LOJ-hAP] > sys ntp cli print
enabled: yes
mode: unicast
primary-ntp: 80.96.120.252
secondary-ntp: 0.0.0.0
dynamic-servers:
status: synchronized
@docmarius:
Ok, do You have an idea how to debug my ntp client and understand what is wrong with it?
Sorry, pasted from the sntp client.
Corrected. The status should state “synchronized”.
First, check if your firewall is passing port 123 UDP…
After that, the simplest way would be to try another time server. Just use pool.ntp.org and you will get one.
@docmarius:
Thanks for help and explanation. Now all is ok, clients get synchronized too.
[boris@MikroTik] /system clock> /system ntp client print
enabled: yes
mode: unicast
primary-ntp: 91.206.16.3
secondary-ntp: 85.21.78.91
dynamic-servers:
status: synchronized