Re: ntpd listening on alias interfaces seems non-trivial
On Sun, 2004-01-18 at 23:31, Marius Olsthoorn wrote:
> Ntp uses its own protocol on top of UDP. Each ntp packet includes source
> and destination addresses of the communication. The ntpd server uses this
> data and checks if a answer came from the same host the request was sent
> to. If this is not the case, it assumes something is wrong.
Whatever the technical reasons, ntp is not happy if the response comes
from a different IP to the one the request was sent to (this doesn't
require IP's in the packet... the client could be just checking the
src/dest IP's match).
> In your setup clients connect to one ip(of the alias) and you send the
> reply via your main interface. These ip's then don't match. I don't think
> it is possible to use alias interfaces with ntpd. If you do get it running
> somehow please let me know.
The problem is ntpd doesn't respond on the same interface it receives a
request on. It responds on the default interface routed to the querying
client. I believe there are bug reports on this;
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209054
I did see a post that claims this was fixed in one of the latest RH
packages, but I'm yet to see confirmation that this is true.
> > I have been attempting, without success, to get ntpd listening on an alias
> > interface on one of my general purpose boxes. It seems that ntpd prefers to
> > listen on localhost:ntp and eth0addr:ntp. It opens a socket for *:ntp as
> > well, but does not respond to queries on other addresses. Here is some LSOF
> > output demonstrating this..:
> >
> > # lsof -p 16667 |grep UDP
> > ntpd 16667 root 4u IPv4 4493134 UDP *:ntp
> > ntpd 16667 root 5u IPv4 4493135 UDP localhost:ntp
> > ntpd 16667 root 6u IPv4 4493136 UDP hostname:ntp
> >
> > I checked the archives, and it seems another poster had similar trouble in
> > Dec'02, but there were no apparent follow-up posts. Google has also been
> > less than revealing on this topic. All suggestions entertained.
The only workaround I know of is to route the ntp responses explicitly
via the alias. You can use iproute2 to try and route only ntp responses
via this alias, but it is non-trivial as iproute2 rules don't allow port
based rule selection.
Another possibility is to use NAT to re-map the response on the way
out... once again, if anyone gets this working, please post how you did
it.
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: