I’m looking for a lightweight mechanism to probe my internal servers and e=public server from time to time to check that they are providing a valid(ish) response. My monitoring platform is macOS (though I could also use Linux at a pinch). macOS has ‘sntp’ but using that has undesirable side effects on the client (monitoring) system [adjusts the clock]. I’d like something similar that doesn’t actually do anything with the response that it receives (other than basic validation).
My public server is in the NTP Pool Prometheus is overkill for what I want (especially given that I don’t already run it). I just want a simple tool that can make a normal client NTP request to a server and do some sanity checks on the response to ensure it is valid. Kind of like SNTP except without doing any actual clock setting. I’m kind of surprised that such a thing does not exist.
Yes, I just noticed that. It’s quite a limitation in general. Luckily my main use case is just to ‘ping’ a server and check the response (-c 1) so not an issue for me
Not sure how one might fix that; is there anything in the NTP protocol that lets a client get the actual IP addresses of the serve’s sources? The client utilities (ntpq, chrony) typically truncate long host names / IP addresses for things like peers or sources but presumably the underlying protocol provides the full address in the command response.
When not querying a specific server implementation with its related management tool, the limiting factor is the NTP protocol, such in the case of this specific tool. NTP itself only has four octets to hold the reference id. That is why, when NTP was readied for IPv6 without changing the packet format, instead of the full IPv6 address, only a hash of that, truncated to four octets, is used.
At the end of the day, the main purpose of the reference ID was to prevent synchronization loops, not so much to learn a server’s upstream server. So from that perspective, it wouldn’t even be necessary to add the IPv4 address of a server’s upstream to the packet, but again some hash could suffice. Only thing is that implementations would need to agree on how to derive the hash for the synchronization loop prevention to actually work. As nothing of the sort is specified in current standards (NTPv4), I believe that is why in case of IPv4 upstream server, it’s still their IPv4 address that gets put into the reference ID field. The upcoming NTPv5 doesn’t strive to be format-backwards-compatible anyhow, so a new approach could be taken (and I think, is being taken, but I’d need to check to be sure).
RFC 5905 says: “If using the IPv4 address family, the identifier is the four-octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address.”
In fact, ntpd long got this wrong by failing to use network byte order (big-endian) for the IPv6 reference ID on the wire, meaning timing loops could fail to be detected between mixed big- and little-endian systems. To minimize loop detection failures amongst the predominant little-endian systems that would be introduced by a straightforward fix, ntpd 4.2.8p19 will store the hashed IPv6 reference ID in little-endian order. That is, the fix will only result in changed behavior on now-rare big-endian systems.
By “nothing of the sort”, I was referring to hashing of the IPv4 address, because it is used as is, because unlike in case of an upstream’s IPv6 address, there is no need to shorten to fit into the four octets field.
Prometheus is overkill for what I want (especially given that I don’t already run it). I just want a simple tool that can make a normal client NTP request to a server and do some sanity checks on the response to ensure it is valid. Kind of like SNTP except without doing any actual clock setting. I’m kind of surprised that such a thing does not exist.