My default hosting setup gives each VM a static /64 and uses RFC 8981 temporary address extensions to vary the address selected for outgoing sessions over time.
I turned up a monitor a few days ago and it looks to be working normally, but the dashboard still displays the initial address that has since rotated out.
Is this just a cosmetic issue, or will it cause problems down the road? I can assign a static IP if there’s a technical need.
I would say it’s mandotary! Same as if you run a NTP Server.
You registered your currrent IP (also vaildated if it’s a ntp server) and this IP is “save” to be used as monitor (or as ntp server).
Hmm, not sure the comparison between servers, and their validation, and monitors is valid. With servers, the IP address is the only thing that indeed correlates the server that was initially validated with the entity that is then subsequently providing service, and is being monitored. But the validation is for ensuring that the user is allowed to register that server, not to validate the server itself, that is done by the monitoring. And due to NTP’s nature, the IP address is what is bound to the server being a server. Changing the address of a server will effectively make the server be a different server, from the perspective of the NTP pool system, and NTP clients. Thus a validation is not transferrable to another address.
With monitors, that is different. During registration, they are linked to an account after a similar validation as in case of a server. But as part of that process, the link of the monitor to the account is moved away from the IP address(es), and bound to an API token and/or a monitor-specific certificate/private key. Those are what after initial registration will be used to identify, authenticate, and authorize the monitor to connect to the pool, and submit measurements. And as the monitor operates as an NTP client, the IP address is also not relevant from that perspective, unlike for a server.
So it would seem, based on current understanding, that a monitor’s IP address(es) is/are actually mostly irrelevant for the actual operation as a monitor, and interactions with the pool system. And any strict dependency on the IP address would seem like an unnecessary implementation limitation, or serving purposes that are more convenience aspects (which may have their own valid reasons), e.g., see in a dashboard what the IP address of a monitor is, without an actual functional requirement. But @msiegen’s experience shows that there doesn’t seem to be a strict requirement from the implementation side on the IP address remaining stable (at least in the short term since the system was put in place), apart from the cosmetic issue, and slight inconvenience, of the dashboard not showing the currently used IP address(es).
That was my experience when my stable-for-years-but-not-static IPv4 monitor address changed. Everything seemed to recover and keep working without issue.
I do think there’s a key difference between a server and a monitor. The server IP is critical; it’s published in DNS and clients may latch onto it for long period of time before they re-resolve. The monitor IPs are not published anywhere AFAIK, and that makes sense because a server should give monitors the same treatment as any random client.
The requirement is that the network doesn’t change.
It’s not strictly enforced[1], but as we’re adding more monitors from more operators it might make sense to start doing so (monitors have to stay within their /24, /48 networks, for example).
[1] The API doesn’t require the connections to come from those IPs, but the NTP code binds the source address (but maybe only if possible?).
With what purpose, i.e., what is it that should be achieved by that?
I guess maybe that the monitor cannot me moved so far as to be in a different network with different characteristics. But the scoring process will slowly adapt to changes in network connectivity anyhow. And abrupt changes can happen even without the IP address, or the characteristics of the immediate uplink/the physical location of the monitor, changing. Just some routing change somewhere upstream. The cause for network characteristic changes will be indistinguishable based just on the effects visible from the outside, so why artificially penalize one when it might not even be noticeable, when the other might be even worse, and cannot be prevented?
One address pair of mine is typically stable for many months, but every now and then, the ISP decides to change it. The IPv6 address will quite likely be outside the /48 of the previous IPv6 address, maybe even outside the /43. And the IPv4 address outside the /24, likely even outside the /20. Both without changing anything with respect to the local uplink characteristics, or even anything within the ISP till packets hit “the Internet”.
Now, whether that monitor of mine exists or not doesn’t make a critical difference. It sits in a zone that has both an ample number of monitors, as well as an ample number of servers. So I am not mentioning this on my behalf. I am happy, and it’s fun, to contribute monitors, and servers, to the pool. But if the rules kick out one or the other, I don’t entirely mind having one less thing for me to worry about.
Rather, part of the exercise of revamping the monitoring system is to make it easier for monitors to join, to increase diversity and coverage. In the hopes this in turn helps increase coverage, diversity, and capacity on the servers’ side. And both especially in regions that are not yet as amply equipped with monitors and servers as my own home region
In that sense, while the underlying issue of monitors moving unexpectedly is something to be kept in mind, and loosely monitored, I am a bit afraid that starting a discussion as to what might happen when the system hasn’t even been fully deployed yet has the potential to generate FUD.
Which in turn has the potential to subtly counteract the intended improvements the new system is intended to bring by introducing artificial limitations to those improvements. And all without any clear indication that there even is a problem (yet), or a problem big enough in comparison to issues entirely outside of active control of the pool anyhow (only reactive, by adapting to external events). Or that the contemplated “solution” would even address the hypothetical problem in a meaningful way.
With what purpose, i.e., what is it that should be achieved by that?
Having some accuracy in the historic data. In the new system it’s pretty fast to re-provision a monitor; but if it’s relevant I could setup something to have the system do it automatically when the IPs change (too much).
Thanks, still digesting and trying to understand, including the ramifications either way.
My point (as with almost everything) is that it should be made as easy as possible to add monitors, except where really essential to maintain system integrity and performance. (And I gather knowing the correct IP address is not something impacting any of those.) Even if it is pretty fast to re-provision a monitor, it is still a hurdle for a monitor operator, however small, that could keep worthwhile monitors from joining the project, or remaining in the project (by periodic manual re-provisioning, be it twice a year, be it once a month, once a week - think not noticing the address has changed, or not remembering that re-provisioning of the monitor is needed, or really having to login to a device that one maybe doesn’t use daily, remember/look up the monitor’s setup command, and with a headless device needing to transfer the URL to register to a separate device with browser). And some effort on the pool staff side, if some even minor manual interaction such as approving is needed.
I.e., however easy it might be, it still may be a hurdle to have to re-provision whenever an IP address changes that could keep people from doing so eventually (think about the drop in monitors over time with the previous system), just to keep the historic data accurate. I don’t know how often that could happen. Rather rarely in my neck of the woods, but that is but a very small part of the world, and my (limited) experience in general with networking in other parts of the world is that (almost) anything is possible, and things may be “normal” there that I’ve never experienced first-hand myself.
So how about just logging with the data the respective IP address, or in a data-efficient way, only when an address changes, so each measurement in the historic record can retroactively be associated with the IP address valid at the time? Could that be sufficient for the purpose you have in mind (admittedly not yet sure I have the complete picture)?
As nothing seems to depend strictly on the IP address from a functional point of view (unlike for servers, for example), going through all the motions of re-provisioning sounds a bit heavy, to me anyway, just to keep the historic record straight (but maybe just because based on my very personal experience with processes that bore that name, “re-provision” sounds like a somewhat heavy process).
I’d argue that the IPv6 privacy scheme is valuable both to the monitor operators and to the pool. For operators because they a modicum of privacy, especially if they can roam within a subnetwork larger than /64. For the pool because it makes slightly more difficult to filter the monitors.
My data center has scheduled an ipv4 change for one of my servers next month. I’ve scheduled the NTP Pool server to delete as soon as the 2-week window opens, and will register the new IP once it is configured.
The new IP will be outside the /24 window, does the monitor get deleted as soon as I confirm the action? Should I register the new one before deleting the old one, or will the monitor pool detect the IP change by itself?
Thanks, that’s the kind of guideline I was hoping for. In my case a /48 accurately delineates a network location.
It sounds like that’s not universally true for other folks though. Perhaps the AS number would stay the same, not sure we’d want to rely on that.
Automatic re-provisioning could encourage participation from a more diverse range of networks.
The theory tells that with each monitoring sample appended to the log, the monitoring source IP address should be logged too. That would allow even change of the monitoring IP with high frequency and not affecting the quality of the historic data.