12

The NTP deamon if often used in its simplest mode, which is client/server: you specify one or more server directives in your ntp.conf and your clients will use those servers.

In addition to that, when you run your own NTP servers, it is good practice to peer them together, so if one of them looses connectivity to its upstream servers, it will get time from its peers.

But NTPd can also work with broadcast and/or multicast distribution of time data, with the documentation stating:

broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population

The documentation also says elsewhere:

It is possible and frequently useful to configure a host as both broadcast client and broadcast server. A number of hosts configured this way and sharing a common broadcast address will automatically organize themselves in an optimum configuration based on stratum and synchronization distance.

I can see one obvious administrative benefit: you don't have to manually specify and update your list of NTP servers in the clients ntp.conf, so to me it looks tempting to use broadcast mode even for a small client population (say 5+ clients with 3~4 servers). I expect network traffic to be a little higher with broadcasts instead of client/server associations, but given the usual gigabit ethernet LAN the impact should be negligible unless you have a very very large number of hosts in the same broadcast domain.

At the end of the day, when should broadcast mode be used or avoided? Are there pros and cons I haven't seen?

Improve this question
1
  • Broadcast is a lifesaver when the clients aren't very good. A Symmetricom ND-4 wall clock drifts by 2 seconds daily while nonetheless indicating that it is synced to servers. Sending broadcasts is the only way to keep it right.
    – George
    Mar 20, 2018 at 2:45

2 Answers 2

Reset to default
3

No, the broadcast client mode is not supported on most OSes. The broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode and they are not as useful as they used to be.

If you're adamant about this, you can soldier on...

Linux OS supports broadcast/manycast/multicast, but it imposes a CPU overhead by the virtue of putting older Ethernet NIC and its interface in promiscuous mode (by reading in all packets including packets intended for other hosts).

MacOSX (now macos) can support multicast NTP, but no support is given for it. You can use the following command to enable it:

sudo route -nv add -net 228.0.0.4 -interface en0

Microsoft Windows Time service does not support multicast/broadcast on Windows 2000 Server , Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, much less any of the Windows desktop variants. It used to support multicast NTP (K9 from www.mingham-smith.com/k9.htm provides multicast NTP for Windows 3.1, 95, 98, ME, NT, 2000, XP, 2003, Windows Mobile 2003).

Improve this answer
4
  • 1
    Why does it need to do promiscuous mode?
    – LtWorf
    Mar 7, 2019 at 15:06
  • Many older NIC hardware lack the ability to filter multicast (and for even older ones, broadcast) packets at Ethernet/802.3 MAC layer. It has to do with the two upper bits of the MAC address that represent global (broadcast) and “multicast” local bits of which older NIC hardware are not firmware/FPGA-capable of ferreting out of the mainstream traffic flow. Lack of either bits or both results in NIC being required to be set in promiscuous mode (thus taking in both multicast/broadcast as well as unneeded unicast traffic).
    – John Greene
    Mar 7, 2019 at 15:14
  • It's kinda funny that all most MAC/PHY combos for microcontrollers let you drop the frame after transferring as few bytes over the bus (SPI or parallel) as you want - so you get the frame interrupt, and can determine whether it's multicast or unicast address after just one byte read. Usually, dropping the frame is one more bus transaction then. On architectures where DMA or memory-mapping is used, you either suffer the cost of transferring all frames to main memory, or suffer the cost of loading an entire cache line (64 bytes) from the NIC just to check the address programmatically.
    – Kuba hasn't forgotten Monica
    May 29, 2021 at 0:05
  • Modern microcontroller MAC/PHY combos have pretty good filtering - destination hash table, high-level unicast/multicast/broadcast selection, magic frame detection, pattern match (anywhere in the frame), dropping runt and wrong-FCS frames, etc.
    – Kuba hasn't forgotten Monica
    May 29, 2021 at 0:14
1

In my opinion, broadcast/broadcastclient should be avoided at all times.

I've looked into this option myself and didn't find any suitable way to configure client just to accept those broadcasts from "official" servers only.

And the next point is: How compatible is this broadcasting with Computers running Windows/MacOS?

Improve this answer
1
  • 6
    suitable way to configure client trust = autokey
    – dfc
    Nov 5, 2012 at 2:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .