Visualising RIPE Atlas Anchor Measurements

Introduction

When the RIPE NCC started the RIPE Atlas anchor project, I decided to host an anchor, mainly to help the project. Once done, I realised that a lot of RIPE Atlas probes were sending measurements to my anchor and - even better - the results were freely accessible (this is a built-in feature for RIPE Atlas anchors ). I downloaded the JSON file provided by the RIPE NCC and started to look for useful data. I found data such as source IP, ping time and traceroute paths to my anchor coming from all over the world.

Having this kind of data is very valuable as it provides a picture of the connectivity of my network or autonomous system (AS) in almost real time. There are various use cases: If a customer is complaining that their connection from a certain place in the network is slow, we can check if that is really the case. Or if one of my upstream providers changes the bandwidth profile, we can check if some traceroutes have changed and how.

Methodology

When I saw how useful this kind of information could be for my operations, I started visualising it so that it would provide a clear view of the current quality of service, help debugging network issues and optimise my routing policy. For that I downloaded the JSON file every hour, parsed it and saved it in a database. I kept 5 data sets:

• Source IP
• Source AS
• Source country (using GeoIP databases)
• Ping time
• Traceroute path

Analysing the traceroute paths gave me another useful insight into the AS paths of incoming packets from many ASes. This information is very important as it is the only way to check if BGP prepending and BGP communities are configured since many ASes still don't provide a looking glass . I wanted the visualisation to be simple and clear. I also wanted to make it possible to select data by country and by AS. Please see below some examples (you can click on the images to enlarge them).

Visualisations

The first image (Figure 1) shows the correlation between the AS path and the round trip time (RTT) for each country. We grouped all probes located in one country and measured the average number of hops and the RTT (in ms) towards my anchor. If you hover over one of the dots, you will see some additional information.

Figure 1: Correlation between AS path and time

You can, for instance, see that the number of hops and the RTT from probes in France are low, because they are in the same country as the anchor.

The two maps in Figure 2 basically show the same information, but this time presented on a map: the number of hops on the left and the RTT on the right. This allows us to easily detect latency from certain countries towards our network.

Figure 2: Number of hops and milliseconds needed to reach anchor at SDV

As mentioned above, you can specify a country and time period on top of the page. We use the Maxmind GeoLite database to map an AS to a country. See below the visualisation for ASes in France:

Figure 3: Correlation between AS path and time for ASes in France

Again, you can see the number of hops and RTT from various ASes in France towards our network. We also present this as a graph that shows the RTT over a period of time, which will allow us to detect potential problems (see Figure 4).

Figure 4: RTT (top) and AS path (bottom) from probes in France towards our anchor

Once a country is selected, you can look at the data for a specific AS in that country. See below an example for AS 3215. When you hover over the graph, you will get additional information.

Figure 5: RTT (top) and AS path (bottom) from probes in AS 3215 towards our anchor

You can further drill into the data by clicking on the IP address on the table at the bottom of the page. You will then get all the traceroutes from that probe to the RIPE Atlas anchor (see Figure 6).

Figure 6: Table showing all traceroutes from a specific RIPE Atlas probe to the RIPE Atlas anchor

Conclusion

With the simple data provided by the RIPE Atlas infrastructure, we now have a real monitoring system that gives useful information about our connectivity over time. I use this tool on a regular basis to analyse the quality of our connectivity and topology changes and to help debugging network issues.

The tool is publicly available . Please feel free to play with it and send me your feedback, ideas or bug reports or post a comment below. At the moment the code is not published, but if we see that people are interested we can clean it up and post it on github.