[ntp:questions] ntp server with two default routes misbehaving

Caecilius nospam at spamless.invalid
Mon Apr 21 16:05:51 UTC 2014

On Mon, 21 Apr 2014 13:58:00 GMT, "Jason Rabel"
<jason at extremeoverclocking.com> wrote:
>> I wonder why the change was made in the first place.  Did it improve
>> things for some users? It seems wrong to introduce something that
>> causes problems for some use cases unless it benefits others.
>Maybe sift through the changelog to see if anything stands out? Or search the bug tracker? Harlan could probably answer your
>question on the code change.

Good point, I'll take a look.

>I think someone else's suggestion to use the "listen-on" + wild directive might be another good alternative, but I don't know
>exactly when those were implemented. It might work, or it might end up with the same issue as before.

I tried using "interface listen" to specify just one of the external
interfaces.  That didn't work - in fact, ntp didn't sync at all, and
all the servers stayed in INIT state.  I suspect the problem was that
the outgoing packets were going out on the "wrong" interface, and then
being ignored when they came back on the interface that ntp wasn't
listening on.

I think the option I want is QueryOn, which is discussed here:


But I don't think that's been implemented yet.

>> I wonder if it would cause problems for DHCP users, where the
>> ISP-allocated IP changes occasionally.  It probably wouldn't change
>> often enough to cause a big problem, but it would cause NTP to go
>> unsynchronised from time to time.
>Depends... My router's external IP might change every now and then, but that is upstream from my NTP server. On my LAN (with private
>IPs) it has a fixed IP and gateway so NTP is none the wiser... 

It seems wrong that ntp should be getting so deeply involved in the
network layer unless there's a real benefit to doing so. At the moment
it seems like I need to hide things from NTP by putting it behind NAT,
or using iptables and policy routing to force a specific outgoing

>Have you tried with any of the 4.2.7 development builds? If you use the most current (4.2.7p440) it's probably pretty stable. Most
>of the changes lately seem to do with documentation.

Not yet. I've just used the standard Debian builds for Lenny and
Squeeze.  I'll take a look at other versions and see what results I

More information about the questions mailing list