I just started hosting an NTP server in the pool and I can’t seem to keep its score above 10, any ideas?
The only thing I can see is that the monitor named “every” times out
Here is all the info I have right now
Link to the main pool score is at 10.4 - pool.ntp.org: Statistics for 184.108.40.206
Link to the beta pool score is at 20 most of the time - pool.ntp.org: Statistics for 220.127.116.11
The bandwidth is set at 512 so I don’t think it is getting overloaded
Offsets are all under 50ms
More info below
Any ideas would be appreciated
Here is an NTP ripe measurement I ran, so it’s definitely online RIPE Atlas
Here is a ripe Traceroute RIPE Atlas
Traceroute to 18.104.22.168
1 * *
2 (169.254.74.0) 0.125 0.136
3 (10.253.4.207) 0.146
3 (10.253.4.211) 0.173
4 (10.253.4.147) 11.045 11.041
5 nyk-b4-link.ip.twelve99.net (22.214.171.124) AS1299 0.486 *
6 nyk-bb2-link.ip.twelve99.net (126.96.36.199) AS1299 0.968 0.775
7 * *
8 * *
9 * *
10 * *
11 wylief.dev (188.8.131.52) AS701 5.530 5.473
Thanks for this example @wylie39. I’d have expected the selector process to pick different monitors to find some that works better.
At a glance in the logs it seems like all the monitors have erratic enough results that the system can’t get consensus on some that works.
It might be worth checking if you have a firewall or iptables type setup that’s trying to keep state of all the NTP “sessions” and running out of space.
Welcome, wylie39, and thanks for volunteering your server for NTP service. I added your IP address to my local GPS/PPS ntpd with maxpoll 6 to see how it fares several hours ago:
remote refid st t when poll reach delay offset jitter
o127.127.22.4 .PPS. 0 l 11 16 377 0.000 +0.023 0.012
+184.108.40.206 220.127.116.11 3 u 130 64 16 11.591 +0.597 0.582
It appears from my vantage (18.104.22.168) I’m only seeing responses to a fraction of the polls. The ideal “reach” value is 377 representing all 8 recent polls got a response. The value 16 (octal) indicates only 3 of the last 8 queries got responses.
I hope Ask’s suggestion to check for stateful firewalling misbehaving leads you to a solution.
I ran my usual traceroute with UDP-dst = 123 and UDP-dst=37 from a server in London.
I believe there is a port-specific block somewhere on the path.
Unfortunately a number of hops do not participate in traceroute. First column is # replies
This is what port 123 probes show.
8 4 ICMP:TTL 22.214.171.124
8 5 ICMP:TTL 126.96.36.199
8 6 ICMP:TTL 188.8.131.52
7 7 ICMP:TTL 184.108.40.206
8 9 ICMP:TTL 220.127.116.11
4 13 18.104.22.168 (NTP server)
Port 37 probes should no losses at the NTP server.
Wylie, try doing a traceroute from your NTP server to 22.214.171.124.
You won’t get a response, but the results may indicate which ASN is doing rate limiting.
[Zayo and Telia are two common culprits]
Thanks, everyone, I seem to have it all set, moved the server from a proxmox lcx to a VM and it seems to be working fine.
Thanks for the update, @wylie39!