Score won't stay above 10

Server operators
1

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 71.162.136.44
Link to the beta pool score is at 20 most of the time - pool.ntp.org: Statistics for 71.162.136.44
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

2

Here is an NTP ripe measurement I ran, so it’s definitely online RIPE Atlas
Here is a ripe Traceroute RIPE Atlas

3

Traceroute to 71.162.136.44
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 (62.115.180.4) AS1299 0.486 *
6 nyk-bb2-link.ip.twelve99.net (62.115.114.180) AS1299 0.968 0.775
7 * *
8 * *
9 * *
10 * *
11 wylief.dev (71.162.136.44) AS701 5.530 5.473

4

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.

5

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
+71.162.136.44   208.90.144.53    3 u  130   64   16   11.591   +0.597   0.582

It appears from my vantage (96.9.224.210) 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.

6

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 138.197.251.142
8 5 ICMP:TTL 83.231.181.121
8 6 ICMP:TTL 129.250.4.250
7 7 ICMP:TTL 129.250.3.190
8 9 ICMP:TTL 129.250.3.244
10 noresponse
11 noresponse
12 noresponse
4 13 71.162.136.44 (NTP server)
Port 37 probes should no losses at the NTP server.

Wylie, try doing a traceroute from your NTP server to 178.62.9.15.
You won’t get a response, but the results may indicate which ASN is doing rate limiting.
[Zayo and Telia are two common culprits]

7

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.

1 Like
8

Thanks for the update, @wylie39!