[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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;


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

Donovan Baarda <abo@minkirri.apana.org.au>

Reply to: