I need to setup a ntp multicast client. To be able to check of my configuration is good, I trIde to setup an NTP multicast server.

My setup :

  • 2 VM of Centos 7, up to date
  • I am using 2 virtual machine in virtualbox, I have setup both with promicius mode : allow all

My problems are :

  • On the server, the multicast entry is reported as stratum 16; is stratum relevant for multicast? Does the client will reject this as the stratum is low? How can I force a lower stratum for a multicast server?
  • My client doesn't seems to see my server, even if my keys file are identical and that I have trusted the key 1 on both sides.

Using instructions for orphan, it doesn't seems to lower the reported stratum for the multicast address :

ntpq -n -p
     remote           refid      st t when poll reach   delay   offset  jitter
*   4 u   14   64  377    0.454    2.267   1.479       .MCST.          16 u    -   64    0    0.000    0.000   0.000

And my client still doesn't seems to be able to find a server on the address.

I have checked on the server vm, my host machine, and on the client vm, they all see the server multicast messages (for vm : using tcpdump, for host : using wireshark).

On client, using ntpq -n -p will return this :

No association ID's returned

On the client, my config file have all restrict instructions commented, and I only have these (and some more like driftfile and such) :

keys /etc/ntp/keys
trustedkey 1

ntpd client log gives me this :

systemd[1]: Starting Network Time Service...
ntpd[11076]: ntpd 4.2.6p5@1.2349-o Tue Jun 23 15:38:18 UTC 2020 (1)
systemd[1]: Started Network Time Service.
ntpd[11077]: proto: precision = 0.052 usec
ntpd[11077]: c01d 0d kern kernel time sync enabled
ntpd[11077]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
ntpd[11077]: Listen and drop on 0 v4wildcard UDP 123
ntpd[11077]: Listen and drop on 1 v6wildcard :: UDP 123
ntpd[11077]: Listen normally on 2 lo UDP 123
ntpd[11077]: Listen normally on 3 enp0s3 UDP 123
ntpd[11077]: Listen normally on 4 lo ::1 UDP 123
ntpd[11077]: Listen normally on 5 enp0s3 fe80::a00:27ff:fec1:cc1 UDP 123
ntpd[11077]: Listening on routing socket on fd #22 for interface updates
ntpd[11077]: Listen normally on 6 multicast UDP 123
ntpd[11077]: Joined socket to multicast group
ntpd[11077]: c016 06 restart
ntpd[11077]: c012 02 freq_set kernel 0.000 PPM
ntpd[11077]: c011 01 freq_not_set
ntpd[11077]: io_setbclient: Opened broadcast client on interface #3 enp0s3
  • What does ntpq -np return on the time server? Until you've got a decent time source nothing will synchronise to it – roaima Aug 10 '20 at 11:51

Stratum 16 indicates the NTP server does not believe it has a valid time because it has no connection to any configured time source. In order to make ntpd on the server system trust the system's local clock as a time source, there are two options:

  • The modern method is to specify the tos orphan and tos orphanwait keywords in the ntp.conf file on the multicast server.
# If orphaned, serve others with this stratum.
tos orphan 8
# Wait for this many seconds before starting to serve others (default is 300 s)
tos orphanwait 1
  • The older way is to tell ntpd to use the local clock as a fake time source on the multicast server. This configuration should not be used together with real NTP time sources, as it might cause ntpd to believe the local clock instead of the real NTP sources, unless a sufficient number of external sources have been configured and are in good enough sync with each other to out-vote the pseudo-source (which is always perfectly in agreement with the local clock so it tends to get excessively favored by the ntpd selection algorithm).
server iburst
fudge stratum 8

The IP addresses starting with 127.127.* are special for ntpd: they refer to various reference clock drivers built into ntpd.

Both of these methods will make the system serve the UTC time based on the local unsynchronized system clock over NTP using stratum 8, so any systems with a reasonably direct connection to a real NTP time source (= stratum 7 or less) should prefer it over this one.

Using the newer way is recommended whenever your version of ntpd supports it, since with it you don't have to remember to remove the pseudo-source if/when you add real NTP time sources to the system.

  • Thank you, I must have missed something, as on the server, this doesn't seems to do anything. I will edit the question. – iXô Aug 10 '20 at 11:13
  • Was the ntpq -n -p output from the multicast client or the multicast server? CentOS 7 might have just old enough version of ntpd that its implementation of the orphan option may be buggy. Try the older way, and ensure that the multicast server has an asterisk on the leftmost column on its ntpq -np output before even looking at the multicast client. You might want to change the server line to server iburst to speed up the start-up phase of ntpd. – telcoM Aug 10 '20 at 11:25
  • On the server, I am a client of another ntp instance, could this be a problem ? It is selecting this server as preferred (like you can see in my Edit #1) and the multicast packets are received on the client vm (checked via tcpdump) – iXô Aug 10 '20 at 11:45
  • 1
    If the ntpd -n -p output is from the multicast server, then the line with is saying that the multicast server is not receiving any NTP multicasts from other servers and so the stratum level of its multicast client function is at 16; it does not mean the server is sending multicasts at stratum 16. Did you add the multicastclient line to the multicast server too? Does the multicast server's configuration have a line like broadcast ttl 1? (adjust TTL to suit your network requirements) – telcoM Aug 10 '20 at 11:57
  • 1
    Exactly, to both of your comments. – telcoM Aug 10 '20 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.