The RIPE Atlas project employs a global network of probes and anchors that measure Internet connectivity and reachability, and users can define their own measurements to the destination of their choice.
Anchors actively measure Internet infrastructure globally, providing an unprecedented understanding of the state of the Internet in real time.
Below is a blog post, authored and shared by Stéphane Bortzmeyer, Network and systems architect at AFNIC, about how you can use RIPE Atlas anchors to check you Internet connectivity. This story originally appeared on RIPE LABS – Checking your Internet Connectivity with RIPE Atlas Anchors .
APNIC-supported Atlas anchors are deployed in India, Maldives, Nepal, Pakistan, Philippines, Singapore, and Sri Lanka. Discussions are in progress to deploy anchors in other economies in the Asia Pacific.
You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/
If you monitor your external Internet connectivity, you may wonder which machine is the best to ping. Hesitate no more – you can use RIPE Atlas anchors as landmarks.
You may need to check and monitor the Internet connectivity on your site because other tests or services (for instance the reachability of your outside servers) depend on it. Or maybe you want to monitor it to find out how reliable your Internet access provider is.
It is common practice to ping a certain machine as a landmark to verify your Internet connection. You may use a machine which belongs to you, one outside of your premises or a public Internet server. Using a public Internet server, for example Google Public DNS, is questionable. It’s not your machine, it is not free to use and it may stop answering pings at any moment (this is the case with www.ripe.net and labs.ripe.net). If every small LAN pings 2001:db8:433::1 (the example IPv6 adress) every three minutes, and there are ten millions small networks doing it, 2001:db8:433::1 will receive 50 kp/s. This is reminiscent of a famous problem of many machines banging on one server.
Having public services explicitly devoted to these ping tests would be nice. There are a few such as fap.cymru.com, ping.rezopole.net or ping.ovh.net. They do not appear to be clearly documented (with usage policy), maybe because their managers do not want to attract too much attention.
But one landmark is not enough. Each landmark, even well-connected and professionally managed, can break or be unreachable. You don’t wan’t to receive a warning from your monitoring system at 2:00 in the morning if a remote landmark, that you do not control, went down. You need to ping N different machines, and you need to decide that there is a problem only if M of them (with M < N) are unreachable. If only there was a better way…
RIPE Atlas anchors
…but wait, there is! With RIPE Atlas anchors, you can have many pingable machines at your disposal. These servers are located in many places around the world (complete list online). Their main job is to be used as targets in measurements, typically by the RIPE Atlas probes. Using the anchors to monitor Internet connectivity is less common but very useful.
Monitoring plugins
For the rest of this article, I’ll discuss the use of the monitoring software Icinga.
Icinga is a fork of Nagios, it is free software and it uses the same monitoring plugins as Nagios and the other programs derived from Nagios.
One of these plugins, check_cluster, is part of the standard Monitoring Plugins distribution and performs tests on several machines and raises an alarm only if more than a given threshold are down (you choose the threshold). To configure it, you create a group :
Then, you make a template for RIPE Atlas anchors and each item of the group (here, I will define only the first anchor):
The template has some quantitative parameters (such as testing every five minutes) and a very important “notifications_enabled 0”. We don’t want notifications for every host (a given anchor may come and go) but only for the global service. We now define this service:
The two numbers on the definition of the service (1 and 2) are the number of hosts that need to be down before Icinga declares it to be a warning or a critical problem. The variable HOSTSTATEID tells check_cluster that it needs to compute the result from the state (up or down) of the given hosts. From now on, you will receive alerts from Icinga if two or more of the anchors are down or unreachable.
If you want to run other tests on the RIPE Atlas anchors (the anchors have a HTTP server, so you could have HTTP tests), you just define it using the same group.
The web interface of Icinga displays the group this way:
Note here that anchor-us has been down for a few hours but the uptime of “Internet connectivity” is not affected.
An alternative to the monitoring plugin check_cluster is to use check_multi. Unlike check_cluster, it is not part of the official monitoring plugins and you’ll have to download it separately from the website and compile it (as of today, the internal tests of the software seem quite broken). (Most of what follows have been copied from the article “Clustered Checks with Icinga and check_multi“). You then configure it:
Please note that there is another configuration file, specific to check_multi, here test-anchors.cmd. Its content is:
Here I define four RIPE Atlas anchors, then I tell check_multi to monitor them with the plugin check_ping, with parameters “critical if more than 100 ms of RTT or more than 10 % packet loss”. Adjust these parameters depending on your location and the closeness of the chosen anchors. In the example above, all the anchors pinged are in my country, France, and so are quite close.
Another important thing to configure in check_multi are the thresholds. Here, we say that the state is critical if more than two anchors are themselves in a critical state. So, we won’t be disturbed by alarms if only one or two anchors are unreachable.
Which one to use: check_cluster or check_multi? check_cluster is easier to install since it is part of the standard library. check_multi is easier to configure (although the fact it has a separate configuration file, with a new syntax, is problematic) and produces less clutter in the web interface.
Conclusion
There might be reasons why you want to monitor the external Internet connectivity of your network. Now you can use RIPE Atlas anchors to do that.
RIPE Atlas anchors are available as measurement targets in many locations around the world. Monitoring plug-ins such as check_multi or check_cluster can help to automate that.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.