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

Caecilius nospam at spamless.invalid
Tue Apr 22 15:03:27 UTC 2014

On Tue, 22 Apr 2014 10:42:58 GMT, Jochen Bern
<Jochen.Bern at LINworks.de> wrote:

>On 22.04.2014 11:45, questions-request at lists.ntp.org digested:
>> From: Caecilius <nospam at spamless.invalid>
>> 1. tcpdump shows that the packet-level behaviour is the same for ntp
>> 4.2.4p4 and 4.2.6p2. Namely packets to a given peer switch from one
>> source IP to the other approximately every 10 minutes.
>> So the packet-level behaviour hasn't changed between NTP versions, but
>> what has changed is that 4.2.4p4 didn't seem to care wheras 4.2.6p2
>> resets the peer when this happens.
>a) Different OSes have different default behaviors when there are
>several fully equivalent source IPs (including the routes marking them
>as suitable for the target IP in question) to use. It's been a while,
>but IIRC Linux is *not* prone to switching them under your feet. (More
>precisely, what I remember is: SunOS uses the first to have been set up,
>Linux the last, and *BSD round-robins.) Your machine flip-flopping
>instead *might* indicate some problem that the newer ntpd merely made
>more visible.

Yes, I was surprised to see the flip-flopping as I'd thought that the
route cache would make a given target IP stick with a given source
interface.  What's happening in practice is that it sticks for a while
(about ten minutes) and then switches.  I tried reducing maxpoll to
reduce the time between packets to below the route cache timeout of 5
minutes, but that didn't help.

I think there's something about the Linux policy routing load
balancing and route caching that I don't fully understand.  It may be
that I can adjust that to make the routes stick, but that's getting OT
for this group.

>b) Assuming that both the flip-flopping and ntpd choking on it have good
>reasons you cannot or should not ignore, you might want to do what EBGP
>peers do - set up host routes that nail down which ISP connection (and,
>supposedly, which source IP) will be used for which peer. (Of course,
>EBGP and other EGPs do that because they need the peering to work
>*before* they receive information from the peers and populate the local
>routing tables with it.)

That's not a long-term option for me, as I use the pool servers,

server 0.uk.pool.ntp.org iburst
server 1.uk.pool.ntp.org iburst
server 2.uk.pool.ntp.org iburst
server 3.uk.pool.ntp.org iburst

These will resolve to different IPs each time ntp is started, and I
don't know of any way to determine the full set of servers in the UK

>								J. Bern

More information about the questions mailing list