[ntp:hackers] Configuration addition for ntpd

Heiko Gerstung heiko.gerstung at meinberg.de
Thu Mar 1 00:22:17 PST 2007


Danny Mayer schrieb:
>> Hi Guys,
>>
>> are there any news on the configuration file rewrite available? There
>> are a couple of feature requests I saw in the past or maybe it is only
>> me who would like to see them and I wonder if there are any of those
>> points already handled in the new configuration file format/parsing.
>>
> 
> We are waiting for Sachin to get back.
Is there any information about how long it will take Sachin before we 
can introduce that into the dev codebase? Is he reading this mailing 
list? Sachin? Are you here? ;-)

>> 1. apply "working" default restrict rules to hosts that are defined as
>> ntp servers or peers in the config file
>>
>> That means, if I have a line like this in my config file ...
>> server my.favourite.ntp.host
>> ... ntpd would automatically apply restrict rules to it which simply
>> allow me to accept time from it. If it is configured as a peer, it
>> should per default be accepted as a peer.
> 
> Yes, that's on my list to implement, but see also below. It's actually
> fairly simple to do. Note however that I believe that there are some
> issues with IPv6 addresses in restrict statements that need to be addressed.

I would not bind that to the IPv6 issues, if it is simple, please add 
it. It would reduce the number of restrict misconfigurations dramatically.

>> Of course it should be possible to add a restrict line for that server
>> in order to override the default restrict statements.
> 
> Right, but preferably do it by name and not just IP address. See also below.
I would do it right after the server line has been parsed and the IP 
address has been determined. Maybe it would help to automatically setup 
a restrict rule for every IP address the server's host name resolved to, 
as soon as we start to use more than the first IP address.

>> 2. add a "dynamic" option to the server/peer config statement
>>
>> This would tell ntpd to re-use the IP address it resolved for this
>> hostname and do not try to resolve it again. An exemption to this rule
>> should be that if the server does not respond at this IP to a couple of
>> requests (i.e. for 4 queries in a row), ntpd should try to resolve the
>> IP again and select another one, if available.
>>
>> These two changes would help us getting rid of the problem with setting
>> restrictions for pool servers or other servers with multiple (maybe
>> round-robin based) DNS entries. The "dynamic" statement could also be
>> used to solve the problem of ntpd running on a server 24/7 for 12 months
>> and trying to request time from a dead pool server that did not respond
>> for the last 3 months.
>>
> 
> This is where it gets interesting. Currently when the code does a DNS
> lookup for a server it may get a bunch of addresses back but we take the
> first one and throw the rest of them away. We shouldn't be doing this.
> There is in fact a BCP on this that very few network applications
> follow. SSH seems to be one of the few that do the right thing. We
> should be keeping all of the addresses that we retrieve and try them one
> after another until we succeed. There are several issues with doing this.
> 
> 1) The server may not be available initially for any reason. So how long
> should we wait or rather how many times should we try to reach the
> server before we decide that it's a bad address and try a different one.
> Obviously we should make this configurable but we need to have an
> default setting.
Per default I would like to see a round robin approach, where you try to 
reach the first IP address of a host and, if it is unreachable, try the 
second address after a short delay (8 seconds, maybe). Then go on to the 
third address and, after the last address you got for the hostname, 
maybe pause 64 seconds before you start again with the first address.

As soon as you reached the host, you should continue using that address 
and (if the "dynamic" flag has been set) only restart whenever it is not 
reachable for a large number of queries (e.g. 16 failed attempts in a row).

> 2) The server may be available but at some point it disappears. How long
> should we wait or rather how many times should we retry until we try a
> new address?

See above, make it configurable and use a reasonable setting as the 
default value. Maybe we could (as a default value) bind that to the 
client's stability/synchronization status. If, for example, the client 
has a couple of servers that work fine, it could stick with the one 
unresponsive server for a longer period. But if it is the only source of 
time, I would like to see it resolving the hostname and trying a 
different IP address much earlier.

> 3) If we run out of addresses (we reach the end of the list), do we do a
> new DNS lookup? I assume we do.

Yes, that would be a good think. In my scenario (see above), after we 
tried all addresses without success, pause a little bit (e.g. one 
minpoll interval) and restart completely (meaning: resolve the IP 
adresses of the hostname and start to try them all until we reach one of 
them).

> 4) If the restrict is automatic (by IP address), then any failover to a
> new address needs to also failover the restrict statements and that's a
> much more difficult to manage but needs to be done.

Yes. Maybe we could mark the "automatic restricts" and throw them away 
as soon as the address becomes unreachable/unresponsive. And, we could 
setup a new restrict statement when we determined a new IP address for 
that host.

> Please also see Bug #334 which was raised on a related issue.
> 
> Danny

Yes, the fallback to other IP addresses (IPv6 and IPv4) would be really 
useful as well.

But even while we still use the "only take the first IP" approach, we 
could add the "dynamic" flag and the automatic restrict functionality.


Regards,
Heiko



-- 
------------------------------------------------------------------------

*MEINBERG Funkuhren GmbH & Co. KG*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung at meinberg.de <mailto:heiko.gerstung at meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>

------------------------------------------------------------------------

Meinberg radio clocks: 25 years of accurate time worldwide



More information about the hackers mailing list