[time] limiting client requests in NTP 4.2.0
Mon Nov 17 18:51:50 UTC 2003
Thanks for your replies.
> I haven't familiarized myself with the 4.2.0 rate limiting features
Here's a summary of how the limiting feature works, based on a quick
reading of ntpd/ntp_restrict.c and ntpd/ntp_monitor.c:
By default, clients/networks are not limited. You specify that a
client/network is limited by adding "limited" to an appropriate
By default, the limit on the average interval is 5 seconds and the
limit on the minimum interval is 1 second. You can change these limits
using a "restrict average X minimum Y" directive in ntp.conf. X and Y
are measured in seconds and should be integral.
By default, requests from clients that exceed limits are simply
dropped. You can arrange for clients to receive a kiss-of-death by
adding "kod" to the an appropriate "restrict" directive.
When a request is received:
It is matched to a history of previous requests according to the
originating addresses without reference to the originating ports.
(So, all requests from behind the same NAT-firewall appear to come
from the same client.) This history includes the time of the last
request and the average interval between requests.
The interval since the last request is calculated. The average
interval is updated according to:
average_interval += (interval_since_last_request - average_interval) / 8
This acts as a sort of windowing filter. With a constant request
rate, it will asymptotically tend to the true average interval, but
if the request rate is varying, it acts to smooth changes. For
example, in my calculation yesterday I ignored it, but taking it
into account implies the 10th request from a client that uses
ntpdate and then a minpoll of 6 might arrive when the average
interval is only 30 seconds. This means that even my supposedly
conservative limit of 34 seconds on the average might drop a packet
or two from this client.
The first 9 packets are allowed regardless. After that, the average
interval and the interval since the last request are compared to the
limits. If a limit exceeded, either the request is ignored or a RATE
kiss-of-death is returned.
Sending a kiss-of-death seems a bit extreme. If I understand it
correctly, it effectively denies service until the server is
restarted, regardless of the subsequent behaviour of the client.
If requests are simply being ignored and the client backs off, it
should eventually not exceed the limits and service will be resumed.
> Anothing thing is clients coming from behind a NAT-firewall.
Good point. If my server were used only via pool.ntp.org and if all
resolvers rotated addresses, I would not expect to see more than one
request from each network. However, I'm also happy for people to
statically configure my server, and if it happens to be a good one for
them, I have no problem with them using it several times behind the same
firewell. (We have three NTP stratum-3 servers behind our NAT-firewall,
and they have several external stratum-2 servers in common.)
I'm now inclined not to configure limits. I only have a handful of
clients apparently exceeding a minpoll of 6, and there seems to be too
much danger of denying service to two or three otherwise well-behaved
clients requesting service from behind a NAT-firewall.
Dr Alan Watson
Centro de Radioastronomía y Astrofísica UNAM
More information about the pool