Monitoring upgrade

Dear @ask , I am so sorry, but I have to report that the problem is still there (crazy recentmedian score):

Screen capture a minute ago.

@willem your post isn’t helpful when you block out your IP address, there isn’t much we can tell about what’s going on without it. This is a public pool so blocking your IP address is self-defeating anyway.

Thanks!

@NTPman Your servers seem to be all sorted out now.

1 Like

With ip address …

Thanks for fixing it!

When I am monitoring your server with to command:
ntpmon 2a02:a46b:c3c0:123::94 &
(from GitHub - bruncsak/ntpmon: NTP server reachability monitoring)
it is OK most of the time, but there seems to be some missing NTP reply:

03-23 08:39 16.91 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@.@@@@.@@@@@@@@@@@@@@@@@
03-23 08:57 16.91 .@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 09:13 16.55 @@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@.@@@@@@@@@@@@..@.@@@@
03-23 09:25 16.55 @@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@.@@@
03-23 09:43 16.73 @@@@@@@@@.@@@@@@@.@@@@@@@@@@@@@@.@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@.@@@@@@@@@@@
03-23 09:57 16.89 @.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:14 17.05 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@
03-23 10:26 17.19 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:40 17.19 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@...@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 10:57 17.33 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@..@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 11:14 19.39 @.@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@.@@@@@@@@@@@@@@@@@@@@@
03-23 11:29 17.47 @@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 11:40 17.59 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@.@.@@@@@@@@@@@.@@@@@
03-23 11:56 17.71 @@@@@.@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:14 17.93 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@
03-23 12:26 18.04 @@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:44 18.14 @@@@@@@@@@@@.@@@@@@@@@@@@@.@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 12:58 18.14 @@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@..@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
03-23 13:10 17.26 @@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@.@@@.@@@@@@@@@@.@@@@@@@@@@@@@@@@@@@@
03-23 13:28 17.26 @.@@@@@@@@@@@@@@@@@@@@@.@@@@@@@@@@@@@@@

(‘@’ character: received reply, ‘.’ character: no reply received) It looks like it is normal not having score 20.

1 Like

Thanks @NTPman – I looked in the database (and the monitoring log and I think what happened was that the “active” monitors didn’t check your server for so long that the score got calculated based on the “testing” monitors.

It only happened once so you had really good timing! I will add more metrics to figure out if the monitors need to “run faster” (basically bigger batches) or if the serversThanks @NTPman – I looked in the database (and the monitoring log) and I think what happened was that the “active” monitors didn’t check your server for so long that the score got calculated based on the “testing” monitors.

It only happened once so you had really good timing! I will add more metrics to figure out if the monitors need to “run faster” (basically bigger batches) or if the servers to be checked have to be scheduled better. The scheduling logic is basically the same as it always was. I’ve been planning to make it more sophisticated, but wanted to manage how many things changed at once.

2 Likes

where are you testing it from ?

1 Like

I tested from France Telecom - Orange network. A second monitoring point is from Switzerland, 2a00:7580:60:211:: network. It is the same result, many success and rarely no NTP reply received.

Excellent news, thanks a lot!

Does anyone have a server that has reached the maximum score from the sgsin1-1a6a7hp monitoring station?
My NTP server located in Virginia has top score on all monitoring stations except this particular station located in Singapore.

95% - 92% of the servers it monitors gives healthy queries. This is the beauty of the new monitoring system is those routing difference are now accounted for. Some connections are going to have better routes and healthy checks more often then others. However to answer your question yes I have servers that score a perfect 20 from there but then have many others that don’t.

1 Like

@Clock As Chris said, for most servers it’s working fine. It’s not a problem that it doesn’t work for some as long as the system figures out to make another set of monitors the “active” ones for that server.

I’m hoping data like this will be helpful in identifying network providers or IXes dropping NTP packets after I’ve added a traceroute feature to the monitoring system.

4 Likes

3 posts were split to a new topic: Score logs / json not showing most recent data

The truncated offset values in the legend should be fixed (or at least better) now. Thanks again for reporting it.

1 Like

Ask, could you please hide the identity of these monitors, and maybe even keep some hidden?

From this paper: https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf

Currently, the NTP pool employs a single monitor server,
whose IP can be easily inferred; when a new timeserver is
registered to the pool, the first NTP queries to that server are
made by the monitor. A natural defensive measure, then, is
to extend the pool’s monitoring infrastructure to contain many
monitors and attempting to keep the identities of these servers
hidden. We believe that this will indeed raise the bar for an
attacker and limit its ability to inflict harm. We point out,
however, that preserving the anonymity of “secret monitors”
might prove hard against strategic attackers, as such attackers
can periodically misreport times and keep track of the IPs of
the timeservers that queried them before their server scores
were decreased by the NTP pool.

1 Like

also, this paper from 2023 raise serios concerns about the new monitoring system:

1 Like

I suspect hiding monitors would make debugging routing issues much more difficult. Hidding only IP address can be easily circumvented.

The paper seems to be about 6 months old, it doesn’t describe the current monitoring system using median score. I think the attacker would need to control a majority of monitors.

I like some of the suggestions such as warning about significant increases in the measured delay and falling back to a trusted set of monitors if inconsistencies in reported values are detected.

1 Like

What are the concerns they raise about the new monitoring system? Everything described is about the old system. In some regards the systems are the same, but mostly the new system should be more resilient.

The monitoring server IPs in the new system aren’t explicitly published, but a motivated attacker could easily figure out what they are.

I didn’t read these specific two papers in detail yet, but there have been many over the years. I’m happy to take suggestions for improvements (or after a discussion pull requests on GitHub), but most of the past research along these lines seems like an academic write up of the XKCD (except I am in California and there are a handful of you helping out week to week and a few thousand people running servers).

Dependecy

But yes, a lot of this depends on us running the system and the NTP servers not screwing up. We all do the best we can and have systems in place to mitigate common mistakes and failures. That’s how internet infrastructure generally works, isn’t it? I’d love to learn from other low-budget, volunteer run global internet infrastructure how they do things differently.

One of the concerns brought up in one of the recent papers (I think one of the ones you linked, @giovane) is around a few NTP servers getting disproportionately many of the requests in some countries. Improving on that is one of the next projects on my list now that the new monitoring system is in place.

5 Likes