With the attempted coup in Turkey, reports went out about social media being throttled and/or blocked. We analysed data about this that we collected with RIPE Atlas and the Open Observatory of Network Interference (OONI).
Learn more about the RIPE Atlas active measurements network.
You can also find a collection of use cases, reviews and other articles written by RIPE Atlas users.
Following my recent research on DNS hijacking and the cases I have personally observed, I wondered whether this is a common practice among the operators. With the help of RIPE Atlas, I started to think of a solution to figure out whether such practice is widespread in other areas of the world.
Some of the third version of RIPE Atlas probes have recently had an issue with their USB sticks. We're investigating what may be causing this issue and have a possible solution, outlined below. (At the same time, we're also looking into a new hardware solution for the future.) If you've had trouble with your probe, please follow these simple steps. RIPE Atlas users everywhere will thank you for getting your probe back online - and we will, too!
There are about 600 DNS root server instances deployed around the world. But does everyone have an equal level of access to a root server in their region? Are they fairly distributed? Do all major (and country level) network operators recognise the value in deploying (or peering with) a root server in their network?
The third RIPE Atlas hackathon took place in Copenhagen the weekend before RIPE 72. In this article, we share the details about the hackathon and a preview of the fourth hackathon.
IP anycast has been widely used to replicate services in multiple locations as a way to deliver better performance and resilience. It has been largely employed by CDNs and DNS operators, such as on the root server system. However, there is little evaluation of anycast under stress.
For a while now, the number of active RIPE Atlas probes has hovered around the 9,400 mark. This means that new probes are being connected at a fast enough rate to replace failing probes, but not enough to grow the network. At the same time, the version 3 probes have problems with their USB sticks. This led us to wonder whether these two issues are related.
We've updated the RIPE Atlas APIs - and there's a comprehensive new manual to explain how to use them. As a result, the current (version 1) APIs are still available for now, but will be deprecated by the end of the year.
This work demonstrates the value of the results collected by RIPE Atlas independent of the original purpose for collecting them. Using all traceroute results from a particular day as an example, we first show that near real-time analysis of the result stream is feasible. Then we show that this has great potential for studying the packet layer of the Internet in general and for providing tools to network operators in particular. All this suggests a large and diverse potential for further work.
Detecting network disruptions is a recurring problem. Clearly locating performance degradation is an important step in debugging and subsequently fixing connectivity issues.
This article explains how I use RIPE Atlas probes, the official API and custom scripts, to debug network issues.
Please enjoy this guest post by Agustín Formoso, Software Developer at LACNIC: Regional connectivity is not an easy metric to measure. To do it properly you need measurements generated by multiple vantage points, located in as many places as possible (both geographically and logically). Besides, connectivity is not something strictly defined, as it has no standard definition (as opposed to many metrics we use in today’s Internet).
RIPE Atlas back-end applications run on more than 40 servers. Each day these machines can produce thousands of application logs of any kind of severity level. In order to be able to track down serious errors, warnings or even unusual behaviour, we decided some time ago to try Elasticsearch as a logging sink. In this article we will look at the design of such a system and describe how we can easily make sense from an ocean of logs.
I attended a conference on Broadband Services and Infrastructure Mapping, which I think had some interesting content for RIPE Labs readers.
The IXP country jedi tool described in earlier RIPE Labs articles, can also be used to analyse the situation in a specific city. This time we look at Berlin.
The RIPE NCC has developed an additional interface for the RIPE community mailing lists – something that we hope will encourage more interaction and discussion among the RIPE community.
In February 2011 the RIPE NCC implemented the "pingable:" and "ping-hdl:" attributes in the RIPE Database. These attributes were added to the Routing Policy Specification Language by RFC 5943 to allow networks to advertise IP addresses that are reachable and can be used as a target for diagnostic tests. Five years later we check how the new attributes have been adopted and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas.
In the past few months, we've added some new features and functionality to RIPE Atlas, including making the DNSMON code available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in LatencyMON, new credit sharing options, and new limits on probes per measurement and results per day. Learn more about the latest updates - and don't forget to tell us what you think.
The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers.
A new tool joins the family of applications whose goal it is to take full advantage of RIPE Atlas to monitor availability, consistency and reachability of networks and services: the RIPE Atlas Monitor.