9

I have about 20 Linux servers in a small network and I need their clocks decently close to each other (e.g. within 20msec). I've started with every one of them synced to europe.pool.ntp.org and the job is done.

Now I have two questions:

  1. Am I a noticeable burden to the pool? I.e. does it make any noticeable difference to the pool if I'm hitting from 20 servers or from 2?
  2. If it does make a difference what's the setup/configuration that will keep my subnet synced and the pool under light load? There are guidelines for huge networks (http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101) but I've found none for small networks.
5
  • 1
    Usually you should have one or two internal time servers against which you sync your internal network. Your two internal servers can have a peer relationship. See for example ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101
    – Marki
    Dec 27, 2014 at 20:24
  • Thanks for the comments and link Marki. Regarding the link it notes that it's for "a huge network" which is certainly not my case. Regarding your suggestion: I don't think one internal time server is a good idea (single point of failure) but 2 look like a good idea. Can you explain what a peer relationship is (or provide a link)?
    – ndemou
    Dec 27, 2014 at 20:35
  • Should also note that I'm definitely not an NTP expert - far from it :-)
    – ndemou
    Dec 27, 2014 at 20:41
  • Won't hurt if you google a little about what a peer is. Note that this site doesn't serve anything on a silver platter when people do no research at all themselves.
    – Marki
    Dec 27, 2014 at 20:49
  • Don't get me wrong I did my homework but NTP is one of these subjects where most documentation is either too swallow (this is the ntp.conf - just use it) or too deep (50 pages of theory of operation to read before you can start grasping the basic facts).
    – ndemou
    Dec 27, 2014 at 21:01

2 Answers 2

8
  1. Am I a noticeable burden to the pool? I.e. does it make any noticeable difference to the pool if I'm hitting from 20 servers or from 2?

Given that the pool is in constant need of servers for many years (see [1]) I would say that although 2 or 20 servers don't really make a difference you should always remember that you are not alone. So you better be thinking about say 1000 admins in which case we're talking 2000 or 20000 servers and this does make a difference.

  1. If it does make a difference what's the setup/configuration that will keep my subnet synced and the pool under light load?

You must sync two[2] servers in your network with the pool (let's call them Primary NTP Servers) and then sync all other servers to those two. This method also has the advantage that the time between all your servers will be more closely matched (within less than 1msec). This is in accordance to IETF best practices.

1) The configuration for the Primary NTP Servers

Replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

peer 10.11.12.1  iburst
#      ^^^^^^^^^^^
#      The LAN IP of the _other_ Primary NTP server 
server 0.europe.pool.ntp.org 
server 1.europe.pool.ntp.org 
server 2.europe.pool.ntp.org 
server 3.europe.pool.ntp.org 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Please note that this configuration also permits hosts from all over the Internet to query your host time via NTP queries. Use your firewall if you don't want to. In my example 10.11.12.1 and 10.11.12.2 are the IPs of the Primary NTP Servers (they have two network cards one facing the public internet and one the local 10.11.12.x subnet). Each Primary NTP Server has the other one declared as a peer (peer basically means both server and client - you use the other host as a time source and the other host uses you as a time source also). So adjust the IP on the 1st line so that the configuration of each Primary NTP Server points to the other one as a peer. See [4] regarding my choice to use 4 servers.

2) The configuration for all other servers

2A) If you have two network interfaces

You better use the 2nd interface to create a local subnet (e.g. 10.11.12.0/24) and use that for NTP queries. In that case the restrict lines can be more tight. So again replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

restrict -4 default ignore
restrict -6 default ignore
restrict 10.0.0.0 mask 255.0.0.0 kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

2B) If you don't have two network interfaces

You should use the bellow restrict lines (and read the note about using your firewall to block access to your NTP servers above). So again replace the server and restrict lines of your ntp[d].conf with the following and keep the rest to your distribution defaults[3]:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

Notes

[1] From 2006 to 2012 they constantly ask for more servers to join: the 2006 request, the 2009 one and the 2012 one. Check www.pool.ntp.org for updates on current status.

[2] Two Primary NTP Servers are only suggested as a simple way to have redundancy without complicated High Availability arrangements. You may opt for 3 or 4 for other reasons (again read the IETF best practices)

[3] In practice and no matter your distribution the only other thing you need to include in your ntpd configuration is a line defining a directory to put a drift file and a name for it -- e.g. driftfile /var/lib/ntp/ntp.drift. I've tested my solution in CentOS, Debian and Ubuntu. I guess it works in most other distros.

[4] I've configured 4 pool servers following best practices. Configuring more than 4 servers is technically accepted but you'll increase the load to the NTP pool for a questionable gain in availability so don't do it. In the best practices I see that "starting with ntp-4.2.6, the 'pool' directive will spin up "enough" associations to provide robust time service" so if you use .pool. addresses as I do here and ntp >=4.2.6 the exact number of server lines probably doesn't matter.

Rant Oh! I hate NTP (except that I like that it works). The official documentation is full of obsolete information and they have "how do I use it?" information mixed with scientific details about the internals. And I also hate how restrict 127.0.0.1 really means allow everything for 127.0.0.1


History of updates

I've removed the iburst option from the configuration of the Local NTP Servers because their friendliness to the pool is debatable. (see comments). Removing them only adds a couple of minutes of waiting time to the first synchronization.


Credits

Comments and answers from SF users Marki and Sven provided a good starting point for this answer. Thanks to both of them. Also thanks to SF user BACON a serious mistake was corrected after many years (ndemou's law: "given enough eyeballs and infinite time, all bugs are shallow")

9
  • 1
    +1 from me. I run a pool server, and I can't overemphasise the rightness of this post, except that iburst is an annoying parameter to use on public servers, so please don't (though it's nothing like as annoying as burst). Pool server admins are doing you a favour without knowing who you are, and without any recompense to themselves, purely for the better running of the internet. If you, by working harder, can make their lives easier, you owe it to them to do so.
    – MadHatter
    Feb 1, 2015 at 9:54
  • Thanks MadHatter. Regarding iburst, I thought it was OK for typical "always on" servers. Do you have any links to support your advice of not using this option? (I've checked www.pool.ntp.org/en/use.html and also googled for 10min but found nothing conclusive)
    – ndemou
    Feb 1, 2015 at 10:12
  • I will happily share my traffic stats; a quick sample suggests that misconfigured hosts, ie hosts that transmit more frequently than once a minute, make up about 45% of my clients but are responsible for about 75% of the traffic. That will mostly be from servers that use burst, but even iburst says (from the ntpd man page) "with this option a volley of messages is exchanged to groom the data and set the clock in about 10s". Using iburst says "setting my clock quickly is more important than keeping the load on your server low", and that's impolite.
    – MadHatter
    Feb 1, 2015 at 10:24
  • 1
    I think the server 10.11.12.1 iburst peer line is incorrect. That is treating peer as an option for the server command, whereas according to (the NTP documentation and ntp.conf man page server and peer are alternative commands. See also here where it says "A time server expected to both receive synchronization from another server, as well as to provide synchronization to it, is declared using the peer keyword instead of the server keyword." Jun 4, 2020 at 21:56
  • 1
    Yes, the peer HOST syntax works for me to get two internal NTP servers syncing to each other in addition to their respective external (server HOST) hosts. Also, I found in Association Management it says (emphasis mine) "A peer is configured in symmetric active mode using the peer command and specifying the other peer DNS name or IPv4 or IPv6 address. The burst and iburst options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages." Jun 5, 2020 at 15:03
6

The usual approach for this is to use a tiered setup - you sync one or two servers in your network with the pool and then use those as your local time source. This levels are called strata in NTP lingo.

Also, think about it: If you do this like you desccribed, it won't be really noticeable, but if 1000 sites your size start this, you end up with 20k mostly unnecessary requests and at some point, it gets noticeable.

Read http://en.wikipedia.org/wiki/Network_Time_Protocol

6
  • But consider the alternative viewpoint — twenty more clients on top of millions of existing clients is hardly anything. Dec 27, 2014 at 20:32
  • 2
    Like he said, if everyone starts to think that way...
    – Marki
    Dec 27, 2014 at 20:33
  • But at what point do you stop? Think of all the Linksys-class devices that ship preconfigured to use pool.ntp.org. Surely DNS traffic exceeds NTP traffic. Do you also have to cache DNS locally? Even DNS traffic is likely to be miniscule compared to the rest of your bandwidth consumption. Dec 27, 2014 at 20:37
  • @200_success: This isn't worth debating, but most of this "Linksys class" devices do indeed cache DNS traffic locally, and they query their ISP DNS, which caches as well ...
    – Sven
    Dec 27, 2014 at 20:40
  • 1
    If Linksys ship devices that sync to ntp.pool.org they're in violation of the pool terms; if they've done it properly by applying for a vendor zone (see link) then they will also have been expected to contribute to the pool project in proportion to their load (again, see link).
    – MadHatter
    Dec 28, 2014 at 16:48

You must log in to answer this question.

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