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.
ndemou
  • 1,315
  • 3
  • 17
  • 28
  • 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 http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101 – Marki Dec 27 '14 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 '14 at 20:35
  • Should also note that I'm definitely not an NTP expert - far from it :-) – ndemou Dec 27 '14 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 '14 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 '14 at 21:01

2 Answers2

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")

Community
  • 1
ndemou
  • 1,315
  • 3
  • 17
  • 28
  • 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 01 '15 at 09: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 01 '15 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 01 '15 at 10:24
  • You are right about the "volley of messages" but as far as I can understand this burst will only happen during NTP daemon startup and (maybe) if the pool server is momentarily unreachable (i is from initial). Here is an abstract from the Arch wiki NTPd page: "The iburst option is recommended, and sends a burst of packets only if it cannot obtain a connection with the first attempt. The burst option always does this, even on the first attempt, and should never be used without explicit permission and may result in blacklisting". – ndemou Feb 01 '15 at 11:01
  • You are right that `iburst` is a lot less objectionable than `burst`. My point is that when you're using someone else's resource for free, there is an argument that you should bend over backwards to be considerate; merely not being actively inconsiderate may not be thought to suffice. I agree it is said to be best practice, but those documents take no account of whether the upstream servers to which you are syncing are part of your enterprise or not; they dictate *technical* best practice (which, I agree, is to use `iburst`) rather than *social* best practice. – MadHatter Feb 01 '15 at 11:05
  • Thanks for the discussion MadHatter. I've updated my answer removing the iburst option. – ndemou Feb 01 '15 at 15:33
  • 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](https://www.eecis.udel.edu/~mills/ntp/html/confopt.html) and [`ntp.conf` man page](https://linux.die.net/man/5/ntp.conf) `server` and `peer` are alternative commands. See also [here](http://doc.ntp.org/4.1.1/notes.htm) 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." – Lance U. Matthews Jun 04 '20 at 21:56
  • Thanks @BACON. The documentation is very clear on this so I made the change but can you also test it? – ndemou Jun 05 '20 at 05:16
  • 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](http://doc.ntp.org/current-stable/assoc.html#symact) 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." – Lance U. Matthews Jun 05 '20 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

Sven
  • 98,649
  • 14
  • 180
  • 226
  • But consider the alternative viewpoint — twenty more clients on top of millions of existing clients is hardly anything. – 200_success Dec 27 '14 at 20:32
  • 2
    Like he said, if everyone starts to think that way... – Marki Dec 27 '14 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. – 200_success Dec 27 '14 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 '14 at 20:40
  • Thanks for the answer Sven. I guess syncing only one server is bad (single point of failure) so let's consider your other suggestion for syncing two of my local machines to the pool. What special options do I need for these two in my ntp.conf? For example do I need to add one as an NTP source to the other or not? A peer maybe? What can I do for added redundancy (in case both of my local NTP servers are down)? – ndemou Dec 27 '14 at 20:52
  • 1
    If Linksys ship devices that sync to `ntp.pool.org` they're in violation of [the pool terms](http://www.pool.ntp.org/en/vendors.html#vendor-zone); 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 '14 at 16:48