Monitoring stations timeout to our NTP servers

Server operators
61

That is a feature in the works to have monitoring from multiple locations (like on the beta site).

NTT seems to pop up a lot when people have issues with NTP traffic being dropped…

62

http://trace.ntppool.org/traceroute/51.155.16.62

63

Yes they timeout as in the path to use UDP-packets are dropped.
As such you get a bad score.

If you try the beta-server it monitors from Amsterdam and the results are different.
A lot different.

Do not trust the NJ monitoring station as it does not have a clear path to all when it comes to UDP.

Greetings Bas.

64

How do I use the beta server ?

65

Here they are: https://web.beta.grundclock.com/nl/

66

We all have the same problem with the Newark monitor.
You are not alone and people are working to find the cause of the problems.

Just did a tcpdump of 8 hours for Steven to compare the results of my server and what the monitor reports.
As the monitor reports my server bad all the time, the blue-line jumps up and down like a dancer for Newark where LA and Amsterdam reported everything to be fine.

67

Similar problems here @ byrpi2.dynu.net: IPv6 is always super stable (once the server config is final) and IPv4 fluctuates wildly with lots of timeouts in-between…
Any hints what I could try on my side?
Thanks,
Michael

68

@mby Your server doesn’t look too terrible NTP-wise, although there are some issues with ICMP.

IPv4 NTP: https://atlas.ripe.net/measurements/23910167/#!probes
IPv6 NTP: https://atlas.ripe.net/measurements/23910168/#!probes

IPv4 Trace: https://atlas.ripe.net/measurements/23910177/#!probes
IPv6 Trace: https://atlas.ripe.net/measurements/23910179/#!probes

IPv4 Ping: https://atlas.ripe.net/measurements/23910187/#!probes
IPv6 Ping: https://atlas.ripe.net/measurements/23910192/#!probes

When you say that IPv4 is fluctuating wildly, what do you mean by that?

69

Thanks and I mean that IPv4 connections seems to have many more timeouts when probed by the pool than IPv6, which works nearly flawlessly:

70

Just two side questions:

  1. are these ip static ? reverse lookup shows up as normal ISP
  2. is the line symetric or asymetric ?
71

It‘s ISP but IPs should never change; and it‘s an asymmetric line.

72

Ok, thought it’s like a dial up which change the ip.

73

@mby What sort of traffic levels (NTP packets per second) are you seeing during the times when the score is below 10?

74

Thanks Steve, and it is always super-low traffic; appalling is that only the IPv4 probes break down while IPv6 is alive and kicking…
But anyways, I’ve monitored the accuracy of my server quite extensively and di some testing, so it does not appear to be a local problem, so I consider this as closed, thank you everyone.

75

P.S.: When looking at the beta site data, I have these statistics, so it looks like something I can’t influence, indeed:
IPv4: Monitoring Station:Newark, NJ, US (7.9)Los Angeles, CA (-49.3)Amsterdam (-0.3)
IPv6: Monitoring Station:Newark, NJ, US (19.5)Amsterdam (19.4)

76

@mby those are delightfully consistent problems!

@stevesommars might be able to help analyze some tcpdump’s if you can work with him. He’s been working out which [ network links / transit providers / etc ] are causing trouble and looking at the failure patterns.

1 Like
77

Thanks @ask, I’m currently working with @stevesommars on it; we’ll keep you posted.

78

@ask would it be possible to get hostnames or IP addresses for the Amsterdam/L.A. monitoring stations? I’d like to compare routing issues between all 3 monitoring stations. I’m currently suffering from packets being dropped from the NJ monitor in the production pool (I believe this is zayo, but our networks team will be able to dive deeper into this).

Any help would be great as this is negatively affecting our polling and our NTP service is one of very few in IE.

79

I see you deleted your servers.

UDP’s can be dropped anywhere, and it happens often.
Cisco is telling people that 5% drops on UDP is acceptable.

Yes the score of the pool is based on 1 monitor and 1 monitor alone, and it needs a few misses to kick you out of the pool.

As often said here, there must be more monitors and it must at least average on those, but in fact 1 monitor reporting you as GOOD should be enough.

The beta-system does and my servers are marked by LA as good and dismissed by Newark (as usual).

Yet the system still isn’t fixed. It’s 6 months now…the beta system is 10000000x better then this.

No @Ask, there is no NTP filtering, it’s simply not true. ISP’s use NTP themselves to keep time!

80

@HEAnet LA is 45.54.12.11, the Amsterdam one is monams1.ntppool.net.

1 Like