I have an ntpd ver. 4.2.8p15 that gets its time from the Pool Project using "pool pool.ntp.org". I don't understand why it will sometimes associate with a stratum-1 peer using a 64 s poll interval, never backing off to 1024 s, while using a 1024 s poll interval with all other peers. It's not always the same IP address so presumably not always the same peer. If I remember correctly, every "problem" peer has had a .GPS. refid.

The only practical problem I see with this is more traffic between my host and the stratum-1 peer. That's fine with me, but not fair to the peer.

I don't see an issue with the uplink. The effective rate up/down is 800 Mbit/s (speedtest-cli). Connections to peers are under 50 ms delay and under 1 ms jitter.

Reach, delay, offset, and jitter for the "problem" peer are no different from the others. In fact the "problem" peer is generally a member of the survivor list, and is sometimes the sys_peer.

What events in the log, or variables on the association, should I be looking at to understand how this is happening?

On Mon, 24 Oct 2022 12:51:06 -0700 (PDT), Edward McGuire
<metaed@gmail.com> wrote:

> I have an ntpd ver. 4.2.8p15 that gets its time from the Pool
> Project using "pool pool.ntp.org". I don't understand why it
> will sometimes associate with a stratum-1 peer using a 64 s poll
> interval, never backing off to 1024 s, while using a 1024 s poll
> interval with all other peers. It's not always the same IP
> address so presumably not always the same peer. If I remember
> correctly, every "problem" peer has had a .GPS. refid.

I asked about this back in April this year. It's the way the
servers have been set up; the servers I have observed always
return a poll of 4. Hence clients will never back off from their
minpoll.

> The only practical problem I see with this is more traffic
> between my host and the stratum-1 peer. That's fine with me, but
> not fair to the peer.

The server admin is presumably happy so don't worry about it.

Alternatively you can add restrict lines to your ntp.conf thus

restrict 85.199.214.98 ignore

The above address is from a block of five 85.199.214.98-102
which all return poll 4. To catch all five I use this

restrict 85.199.214.96 mask 255.255.255.248 ignore

Okay so that line stops more than those five IP addresses but I
don't care. If you do care just use five restrict lines with one
IP address on each line.
--
Roger

On Monday, October 24, 2022 at 4:15:06 PM UTC-5, Roger wrote:
> I asked about this back in April this year. It's the way the servers have been set up; the servers I have observed always return a poll of 4

Thank you! I went back to the April thread, and learned these peers are actually not adhering to protocol. Not causing a problem that I see, but out of an abundance of caution I want to punch out nonconforming peers. Today's was 17.253.2.123, returning a poll of 6. Here was my experience.

After adding "restrict 17.253.2.123 ignore" to ntp.conf, I tried to punch the peer out dynamically, but neither of these worked on their own:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config restrict 17.253.2.123 limited kod nomodify notrap nopeer noquery

Without checking the source, I presume this is because access control is enforced only at association creation time. So I've done:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config unpeer 17.253.2.123

and of course that did delete the association. Now I'll just have to keep an eye on the peer list and see if it comes back.

Cheers!
Edward

On Mon, 24 Oct 2022 15:39:18 -0700 (PDT), Edward McGuire
<metaed@gmail.com> wrote:

>On Monday, October 24, 2022 at 4:15:06 PM UTC-5, Roger wrote:
>> I asked about this back in April this year. It's the way the servers have been set up; the servers I have observed always return a poll of 4
>
> Thank you! I went back to the April thread, and learned these
> peers are actually not adhering to protocol. Not causing a
> problem that I see, but out of an abundance of caution I want to
> punch out nonconforming peers. Today's was 17.253.2.123,
> returning a poll of 6. Here was my experience.
>
> After adding "restrict 17.253.2.123 ignore" to ntp.conf, I tried
> to punch the peer out dynamically, but neither of these worked
> on their own:
>
>ntpq> :config restrict 17.253.2.123 ignore
>ntpq> :config restrict 17.253.2.123 limited kod nomodify notrap nopeer noquery
>
> Without checking the source, I presume this is because access
> control is enforced only at association creation time. So I've
> done:
>
>ntpq> :config restrict 17.253.2.123 ignore
>ntpq> :config unpeer 17.253.2.123
>
> and of course that did delete the association. Now I'll just
> have to keep an eye on the peer list and see if it comes back.

Put the restrict line in ntp.conf and that server will always be
ignored even if you have to restart ntpd or reboot the computer.

The reason I have seen it is that I'm in the UK and therefore
using the UK pool servers. The IP addresses I posted are all in
the UK pool. The server you mentioned is, I think, in New York
City.
--
Roger

On Tuesday, October 25, 2022 at 10:34:35 AM UTC-5, Roger wrote:
> The server you mentioned is, I think, in New York City

It's usnyc3-ntp-003.aaplimg.com, an Apple time server, located in New York City just as you said. It is listed in the pool, along with various other clocks operated by Apple, ISC, Hurricane Electric, Turkcell Superonline, and RIPE, in the name of one person, "possibly" without permission.

:(

Apparently, adding a server to the pool currently requires no proof that you are the server operator (see: <https://community.ntppool.org/t/owner-of-a-server/2493>).

:O==
Pool admins can be alerted to listings needing review, using the form at <https://manage.ntppool.org/manage>, which I have now done.

I'm coming back to this issue because the solution I tried:

ntpq> :config restrict 17.253.2.123 ignore
ntpq> :config unpeer 17.253.2.123

ultimately doesn't work. The "unpeer" drops the pool peer, but later the pool peer is "rediscovered" despite the "restrict ignore". Apparently the client maintains the association indefinitely. Evidence for this is that "ntpdc -n -c reslist" returns:

17.253.2.123 255.255.255.255 0 ignore
17.253.2.123 255.255.255.255 366 source, noquery, nomodify, notrap, limited, kod

The first entry is the "restrict ignore" ACE I entered manually. The second is the "restrict source" ACE that still exists even after the "unpeer".

Short of restarting NTP, or adding an entry to my nftables firewall, is there a way to drop the association with the bad peer so it doesn't keep coming back?