Two groups of machines in two datacenters, VPN line in between. Two NTP 
servers in each datacenter, sync'ing to public servers. Local networks 
are gig ethernet.

Sometimes there seem to be issues with the public servers, so I figured 
I may as well use the "peer" command to at least keep the local servers 
as close to each other as possible, since I've a few clusters where it's 
more important that all members agree on the same time base, even when 
that base might not be very accurate.

So I came up with this configuration for the local NTP servers. Please 
criticize it.

###########################################################
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

# comment out your own name
#
peer ntp1
#peer ntp2
peer ntp3
peer ntp4

driftfile /var/lib/ntp/drift

# allow NTP clients to query this server
#
restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap

# allow local queries
#
restrict 127.0.0.0 mask 255.0.0.0

# disallow everybody else
#
restrict default ignore
###########################################################

-- 
Florin Andrei
http://florin.myip.org/

Florin Andrei wrote:
> restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

I  don't think that will work, as the host names will
 give differing IPs every time?

In more recent versions of NTP:
  restrict source nomodify notrap noquery
 would likely do what you want.

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

Florin Andrei <florin@andrei.myip.org> wrote:
> Two groups of machines in two datacenters, VPN line in between. Two NTP 
> servers in each datacenter, sync'ing to public servers. Local networks 
> are gig ethernet.
>
> Sometimes there seem to be issues with the public servers, so I figured 
> I may as well use the "peer" command to at least keep the local servers 
> as close to each other as possible, since I've a few clusters where it's 
> more important that all members agree on the same time base, even when 
> that base might not be very accurate.
>
> So I came up with this configuration for the local NTP servers. Please 
> criticize it.
>
> ###########################################################
> server 0.us.pool.ntp.org
> server 1.us.pool.ntp.org
> server 2.us.pool.ntp.org
> server 3.us.pool.ntp.org
>
> restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
> restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

This does not work!
The names like 0.us.pool.ntp.org return multiple IP adresses and
the "server" and "restrict" lines will not match.

On Sat, Mar 26, 2011 at 10:36 AM, "Rob" <ineedtoread@RFCs.example.com> wrote:
> Florin Andrei <florin@andrei.myip.org> wrote:
>> ###########################################################
>> server 0.us.pool.ntp.org
>> server 1.us.pool.ntp.org
>> server 2.us.pool.ntp.org
>> server 3.us.pool.ntp.org
>>
>> restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>
> This does not work!
> The names like 0.us.pool.ntp.org return multiple IP adresses and
> the "server" and "restrict" lines will not match.

"Rob" is correct with respect to older ntpd.  See ChangeLog or other
public sources for the timeline, but newer ntpd behaves differently,
and will add a restriction for each of the IP addresses a name
resolves to, where older ntpd added only one.  I predict with such
ntpd the above works fine, but it's far from what I'd recommend.

As unruh explained, with recent-enough ntpd the low-maintenance way to
achieve the same result is to replace the four restrict lines with a
single "restrict source", which defines a prototype restriction
automatically applied to servers the client is using, particularly
handy with the 4.2.7 rework of the "pool" alternative to "server",
which can drop and add servers automatically as conditions change.

You probably want iburst on each of those server lines, to sync the
clock in under 15 seconds instead of a few minutes.

On 03/26/2011 08:46 AM, Dave Hart wrote:
>
> You probably want iburst on each of those server lines, to sync the
> clock in under 15 seconds instead of a few minutes.

I thought that was frowned upon, to use iburst with public servers?

(I do use iburst, from all the other machines to the internal NTP servers.)

-- 
Florin Andrei
http://florin.myip.org/

On 03/26/2011 03:36 AM, Rob wrote:
> Florin Andrei<florin@andrei.myip.org>  wrote:
>>
>> restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>> restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>
> This does not work!
> The names like 0.us.pool.ntp.org return multiple IP adresses and
> the "server" and "restrict" lines will not match.

The ntpd version we're using is pretty old and does not support the 
"source" keyword. Since the local NTP servers are behind a firewall and 
are not reachable from the outside, should this matter at all?

-- 
Florin Andrei
http://florin.myip.org/

Let's assume I upgrade to a newer version that accepts the "source" 
keyword. Then how about this config?

Is there are risk of too many internal servers picking other internal 
servers to sync their time - and not enough servers using external 
sources? Should I skew the selection using "prefer" with the external 
servers?

Ideally, I'd like most of my NTP servers to use the public pool most of 
the time. The peers are there "just in case". But if some of my servers 
sync up preferentially to some other internal servers, that's fine.

############################################
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

restrict source nomodify notrap noquery

# comment out your own name
#
peer ntp1
#peer ntp2
peer ntp3
peer ntp4
peer ntp5
peer ntp6

driftfile /var/lib/ntp/drift

# allow NTP clients to query this server
#
restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap

# allow local queries
#
restrict 127.0.0.0 mask 255.0.0.0

# disallow everybody else
#
restrict default ignore
############################################

-- 
Florin Andrei
http://florin.myip.org/

On Mon, Mar 28, 2011 at 6:47 PM, Florin Andrei <florin@andrei.myip.org> wrote:
>
> Let's assume I upgrade to a newer version that accepts the
> "source" keyword. Then how about this config?
>
> Is there are risk of too many internal servers picking other
> internal servers to sync their time - and not enough servers
> using external sources? Should I skew the selection using
> "prefer" with the external servers?

Prefer only comes into play numbering seconds for the PPS refclock, I
believe.  I think the stratum self-organization will take care of your
internal vs. external concern.

> ############################################
> server 0.us.pool.ntp.org
> server 1.us.pool.ntp.org
> server 2.us.pool.ntp.org
> server 3.us.pool.ntp.org
>
> restrict source nomodify notrap noquery
>
> # comment out your own name
> #
> peer ntp1
> #peer ntp2

No need, ntpd will not configure an address that is local as a remote source.

> peer ntp3
> peer ntp4
> peer ntp5
> peer ntp6
>
> driftfile /var/lib/ntp/drift
>
> # allow NTP clients to query this server
> #
> restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap
>
> # allow local queries
> #
> restrict 127.0.0.0 mask 255.0.0.0

restrict ::1   # ntpq/ntpdc tend to use ::1 before 127.0.0.1

> # disallow everybody else
> #
> restrict default ignore
> ############################################

Seems reasonable to me.

Cheers,
Dave Hart

Florin Andrei wrote:
> On 03/26/2011 08:46 AM, Dave Hart wrote:
>>
>> You probably want iburst on each of those server lines, to sync the
>> clock in under 15 seconds instead of a few minutes.
>
> I thought that was frowned upon, to use iburst with public servers?
>
> (I do use iburst, from all the other machines to the internal NTP servers.)

Afaik ibrust was modified to stay underneath the "abuse threshold" some 
time ago, probably in the same timeframe as the Kiss of Death packets?

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 2011-03-28, Florin Andrei <florin@andrei.myip.org> wrote:

> On 03/26/2011 08:46 AM, Dave Hart wrote:
>
>> You probably want iburst on each of those server lines, to sync the
>> clock in under 15 seconds instead of a few minutes.
>
> I thought that was frowned upon, to use iburst with public servers?
>
> (I do use iburst, from all the other machines to the internal NTP
> servers.)

'burst' is a permanent multiplier which causes a burst of packets to be
sent at expiration of _every_ poll period.

'iburst' is a temporary multiplier which causes a burst of packets to be
sent at expiration of each poll poll period _only_ when a remote time
server is unreachable.

The stable release uses bursts of 8 packets while ntp-dev uses bursts of
6 packets.

Documentation references:

Current Stable --> http://doc.ntp.org/4.2.6p3/confopt.html

"burst -- When the server is reachable, send a burst of eight packets
instead of the usual one. The packet spacing is normally 2 s; however,
the spacing between the first and second packets can be changed with
the calldelay command to allow additional time for a modem or ISDN call
to complete. This option is valid only with the server command and type
s addressesa. It is a recommended option when the maxpoll option is
greater than 10 (1024 s).

iburst -- When the server is unreachable, send a burst of eight packets
instead of the usual one. The packet spacing is normally 2 s; however,
the spacing between the first and second packets can be changed with the
calldelay command to allow additional time for a modem or ISDN call to
complete. This option is valid only with the server command and type s
addresses. IT IS A RECOMMENDED OPTION WITH THIS COMMAND." (emphasis
added)

NTP Dev --> http://www.eecis.udel.edu/~mills/ntp/html/confopt.html

"burst -- When the server is reachable, send a burst of packets instead
of the usual one. This option is valid only with the server command and
type s addresses. It is a recommended option when the maxpoll option is
greater than 10 (1024 s). Additional information about this option is on
the Poll Program page.

iburst -- When the server is unreachable, send a burst of packets
instead of the usual one. This option is valid only with the server
command and type s addresses. IT IS A RECOMMENDED OPTION WITH THIS
COMMAND. Additional information about this option is on the Poll Program
page." (emphasis added)

Poll Program page http://www.eecis.udel.edu/~mills/ntp/html/poll.html

"The burst options can result in increased load on the network if not
carefully designed. Both options are affected by the provisions
described on the Rate Management and the Kiss-o'-Death Packet page. In
addition, when iburst or burst are enabled, the first packet of the
burst is sent, but the remaining packets sent only when the reply to the
fist packet is received. If no reply has been received after a timeout
set by the minpoll option, the first packet is sent again. This means
that, even if a server is unreachable, the network load is no more than
at the minimum poll interval."

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

On 3/28/2011 1:16 PM, Florin Andrei wrote:
> On 03/26/2011 08:46 AM, Dave Hart wrote:
>>
>> You probably want iburst on each of those server lines, to sync the
>> clock in under 15 seconds instead of a few minutes.
>
> I thought that was frowned upon, to use iburst with public servers?
>
> (I do use iburst, from all the other machines to the internal NTP servers.)
>

iburst is seldom a problem for a server.  Iburst sends something like 
eight NTP request packets at two second intervals during startup.  This 
is enough to fill the filter pipeline and get an initial value for the 
correct time.

Few people would object to this.

Burst mode is somewhat different.  It sends several requests at each and 
every interval.  Its use is seldom appropriate and is almost always 
unwelcome unless YOU own the server or have the owner's permission!
ISTR that burst mode was intended for use by clients using dialup 
telephone lines to query the server.

On 2011-03-25, Florin Andrei <florin@andrei.myip.org> wrote:

> Two groups of machines in two datacenters, VPN line in between.

A VPN will introduce jitter into any associations between your two data
centers. An unencrypted UDP connection would be better.

> Two NTP servers in each datacenter, sync'ing to public servers. Local
> networks are gig ethernet.

GigE introduces some packet queueing issues ... but that's not relevant to
this article.

> Sometimes there seem to be issues with the public servers, so I figured 
> I may as well use the "peer" command to at least keep the local servers 
> as close to each other as possible, since I've a few clusters where it's 
> more important that all members agree on the same time base, even when 
> that base might not be very accurate.
>
> So I came up with this configuration for the local NTP servers. Please 
> criticize it.

Assuming that your LAN time servers are behind a firewall (or NAT) and
the NTP port is not forwarded I'd rewrite your configuration as:

********************************************************************

driftfile /var/lib/ntp/drift

# Default restrictions
restrict default nomodify notrap noquery
restrict 127.0.0.0

# Authorized clients
restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap

# Internal peers. ntpd will ignore itsself
peer ntp1
peer ntp2
peer ntp3
peer ntp4

# Remote time servers
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst
server 3.us.pool.ntp.org iburst

********************************************************************

You may also wish to consider the use of Orphan Mode (or, depending on
the version of NTP you're using, the Undisciplined Local Clock) to
provision a "local master" in the event you lose your external network
connections.

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

Florin Andrei wrote:
> On 03/26/2011 08:46 AM, Dave Hart wrote:
>>
>> You probably want iburst on each of those server lines, to sync the
>> clock in under 15 seconds instead of a few minutes.
> 
> I thought that was frowned upon, to use iburst with public servers?
> 
> (I do use iburst, from all the other machines to the internal NTP servers.)
> 

It is usually acceptable to use "iburst" as long as you are not
repeatedly restarting ntpd.

There is also "burst" which IS frowned on and you should have
had permission from the target server sysadmin before using it.


David

Florin Andrei <florin@andrei.myip.org> wrote:
> On 03/26/2011 03:36 AM, Rob wrote:
>> Florin Andrei<florin@andrei.myip.org>  wrote:
>>>
>>> restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>>> restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>>> restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>>> restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
>>
>> This does not work!
>> The names like 0.us.pool.ntp.org return multiple IP adresses and
>> the "server" and "restrict" lines will not match.
>
> The ntpd version we're using is pretty old and does not support the 
> "source" keyword. Since the local NTP servers are behind a firewall and 
> are not reachable from the outside, should this matter at all?

I don't have those paranoid restrict statements in the NTP servers on
our LAN...  and on an internet facing server I have only:

restrict default nomodify nopeer notrap


I fail to see what all those paranoid restrict statements are good for.

Florin Andrei wrote:
> Let's assume I upgrade to a newer version that accepts
>  the "source" keyword.  Then how about this config?
>
> Is there are risk of too many internal servers picking
>  other internal servers to sync their time - and not
>  enough servers using external sources?
> Should I skew the selection using "prefer" with the
>  external servers?
>
> Ideally, I'd like most of my NTP servers to use the
>  public pool most of the time.
>   The peers are there "just in case".
>  But if some of my servers sync up preferentially
>   to some other internal servers, that's fine.
>
> server 0.us.pool.ntp.org
> server 1.us.pool.ntp.org
> server 2.us.pool.ntp.org
> server 3.us.pool.ntp.org

pool us.pool.ntp.org iburst preempt prefer  # current NTP will spin up as many as it needs (up to maxclock).


> peer ntp1 iburst
  peer ntp2 iburst # NTP tosses loops by itself, not necessary to comment out your own name
> peer ntp3 iburst
> peer ntp4 iburst
> peer ntp5 iburst
> peer ntp6 iburst
>
> driftfile /var/lib/ntp/drift
>
> restrict source nomodify notrap noquery

restrict source nomodify notrap  # noquery seems unnecessary on that line?


> restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap # allow NTP clients to query this server

As long as _all_ your peers and clients are within XXX.YYY.ZZZ. IP space?


> restrict 127.0.0.0 mask 255.0.0.0 # allow local queries
> restrict default ignore # disallow everybody else

# Perhaps
tos cohort 1              # allows sync to server at the same stratum
tos minclock 5 minsane 4  # only for your servers / peers

# manycast can be used to allow your clients to automatically discover your servers, e.g.
keys "/etc/ntp.keys"      # e.g. contains: 123 M YOUR_MD5_KEY
trustedkey 123
manycastclient 224.0.1.1 key 123 preempt prefer
manycastserver 224.0.1.1  # only for your servers


-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.