[ntp:hackers] Per-Peer Source Address Configuration

Danny Mayer mayer at ntp.org
Wed Jun 10 02:53:12 UTC 2009


John Marshall wrote:
> (CONTEXT: NTP Stratum 2 Server Admin using 4.2.4p7)
> 
> I thought it might be useful to step aside from the technical and policy
> arguments and provide a perspective from a Stratum 2 server
> administrator.  I am not a programmer.  I administer some Stratum 2
> servers in several locations around the planet and have version 4.2.4p7
> running on each of them.
> 
> Being able to specify the source address for servers or peers would be a
> big win.  I have a situation on one server where the default source
> address on the public interface is an address which the datacentre
> reserves for its own network (i.e. the address will probably change if
> they reconfigure their datacentre).  They provide alias IP addresses for
> the public interface and request that only those addresses be used for
> offering public services.  In a situation where an upstream Stratum 1
> server restricts access by IP address, I am forced to supply the
> 'not-for-public-consumption' default IP address which is different to
> the ntp.example.com address we advertise in DNS for the Stratum 2
> service.  I would like to be able to use the ntp alias IP address as the
> source address for access to the upstream servers.  That is a corner
> case, but on other servers the peer source address (default) is often
> also different from the advertised NTP service address (alias).
> 
> I would envisage this being done via an additional configuration file
> server/peer option such as 'srcaddr 192.0.2.21', to fit with the current
> peer configuration grammar (e.g. 'minpoll 4') without breaking parsing
> of the earlier part of the line.  With no per-peer source address
> specified, ntp_peer.c could just figure out the most appropriate source
> address as it does at the moment.
> 
> I am suggesting per-peer source address configuration rather than a
> global query-on address because of situations where a server is
> multihomed and peers with both internal and external servers.
> 
> Also, as a nice-to-have, some method of being able control what
> interfaces/addresses ntpd listens on would be good.  The operating
> system I use on all of the servers is FreeBSD 7.2: the -I and -U
> command-line switches seem to be ignored on FreeBSD.  It irritates me to
> have any network service listening where it doesn't need to - but I know
> it's doing no harm and I can live with the existing situation.
> 
> NTP is the only service I run on any system where I can't specify a
> bind-to address or listen-on or source address (as necessary).  I can
> configure BIND, Sendmail and other services which have a client
> component as required.
> 
> Thanks for considering my ramblings.  Thanks for all the fine work you
> folks do.  Please accept my apology if this is an unwelcome intrusion
> into this list.
> 

John,

I'm still trying to catch up on my email and noone else seems to have
responded to you. What you are looking for I have called query-on, which
allows you to specify the source address to use for outgoing queries,
and listen-on which allows you to specify which interfaces you want to
use and how to use them. There are write-ups on these proposed options
here: https://support.ntp.org/bin/view/Dev/ListenOn for listen-on and
https://support.ntp.org/bin/view/Dev/QueryOn for query-on. The listen-on
configuration option has been implemented according to that
specification but is waiting review by Harlan before it is pulled into
the development stream. I had an implementation of query-on but it needs
to be redone to conform to the specification given in that reference.
Again Harlan needs to approve it.

There is an additional discussion going on for both these options here:
https://support.ntp.org/bin/view/Dev/NtpdAndNetworkSockets so feel free
to add your own comments to that. These two options sound like they are
exactly what you need.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the hackers mailing list