You are here: Home > Analyse > Internet Measurements > RIPE Atlas > About > FAQ

Frequently Asked Questions (FAQ)


Why the name "RIPE Atlas"?

We believe RIPE Atlas will enable measurement data about the Internet on a new scale and produce different kinds of maps from this data, such as latency maps, reachability maps, etc. An atlas is a collection of maps.

What does the number of "Probes connected to RIPE Atlas" on the opening page mean?

This is the current number of active, connected probes (within a few minutes of caching) in the RIPE Atlas network. The number generally increases as we expand the network, but small fluctuations are always expected because probes come and go all the time. When we have "events" at our colo partners (network hiccups, servers going down for reboots, etc.), a larger number of probes can get disconnected temporarily. They reconnect eventually; depending on the actual issue, this may take anywhere from a few minutes up to an hour or two.

Is there a mailing list?

Yes! Please subscribe to the RIPE Atlas mailing list for announcements about RIPE Atlas and discussions with other members of the RIPE Atlas community: ripe-atlas [at] ripe [dot] net. You can subscribe to this list at

Where can I find more information?

If you your questions aren't answered in the FAQ or on the rest of the website, feel free to contact us at atlas [at] ripe [dot] net.

Hosting a Probe

Why would I want to host a probe?

Hosting a RIPE Atlas probe benefits the entire measurement community. It's also beneficial for you, since you'll continually earn credits for the time that your probe is connected. You can use these credits to conduct your own customised measurements using the entire RIPE Atlas network, which can provide valuable information about the performance of your own network. Find out more about customised measurements.

Can I access the data that is collected by my probe?

Yes. You can find detailed information about your probe, including the measurements it runs, by clicking on your probe under the "My Probes" tab on the probes page. Note that you must be logged into the RIPE Atlas website in order to access your probe's detailed page.

Can I host more than one probe?

In order to create the most topologically diverse network possible, regular RIPE Atlas users are currently only allowed to apply for one probe unless they have a special reason for wanting a second one. If a current probe host tries to apply for additional probes, they need to include an explanation in the "Notes" field on the application form in order to be considered.

Technical Details

What data do the probes collect?

Probes perform built-in measurements, including:

  • Its own network configuration information
  • Current uptime, total uptime and uptime history
  • RTT (round trip time) measurements (on IPv4) to the first and second hops (think about the first two lines in your outgoing traceroutes)
  • Ping measurements to a number of predetermined destinations
  • Traceroute measurements to a number of predetermined destinations
  • DNS queries to root DNS servers (others to come)
  • SSL/TLS queries to a number of predetermined destinations
  • a few NTP or HTTP queries
  • more measurement types may be added in the future

You can look at the results of all of the above on your probe's detailed information page. When you're logged in to the RIPE Atlas website, you can find your probe under the "My Probes" tab on the probes page.

Hosts also have access to the RIPE Atlas network to conduct their own user-defined measurements based on those above. An example might be setting up traceroute measurements in order to determine how networks in a specific country or region access your own network.

Similarly, other RIPE Atlas hosts will have access to your probe in order to conduct their own user-defined measurements. You can always check what user-defined measurements your probe participated in on your probe's detailed information page.

Find our more about user-defined measurements.

How are the probes powered?

You'll need to supply some electricity to the probe through its USB cable. Any USB port capable of supplying 500mA should be fine; it could be a free USB port on your home router, or you can use a USB power adapter. Note that devices that go into sleep mode (monitors with built-in USB hubs, laptops, etc.) are not good enough as they usually stop supplying power over USB when they go into sleep mode.

Is it possible to power the probes using Power Over Ethernet (PoE)?

The probes don't support PoE out of the box, since this would make them much more expensive to manufacture, and very few users would benefit from it. However, since this question comes up occasionally, we looked at options. We've found a potential one. Keep in mind that we haven't tested this, but it looks like a possible device that can take power from a PoE cable and give a 5V output. We'd appreciate feedback from our users about this (or any other) solution.

How does the probe connect to the Internet?

Probe versions 1 and 2 have an RJ-45 Ethernet interface. They don't have WiFi capabilities. Probe version 3 (TP-Link) technically has WiFi capabilities; however, we have not provided the necessary software to support this capability because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy.

This means that you have to connect your probe to a physical Ethernet port. Once this is done, the probe acquires an IPv4 address and DNS resolver information using DHCP, IPv6 configuration using RA, and then tries to look up the controlling infrastructure using DNS and connects over SSH to it on outgoing TCP port 443 (HTTPS).

To make probes stand out in a list of DHCP clients, they use the string "RIPE-Atlas-Probe-<probe-id>" as their DHCP client identifier. However, if the probe doesn't know its probe identifier, which will typically happen after a firmware upgrade, then it will use its ethernet address as client identifier. This means it is required to create two entries to configure a probe statically in DHCP.

If you want to configure a DHCP server, you can use the following example dhcpd.conf snippet, kindly contributed by Alan Barrett:

ddns-update-style none;
subnet <<my subnet>> netmask <<my netmask>> {
    option subnet-mask <<my netmask>>;
    option routers <<address of default gateway>>;
    option domain-name-servers <<address of open resolver>>;
host <<hostname assigned to probe>>-hw {
    hardware ethernet <<MAC address of probe>>;
    fixed-address <<IP address assigned to probe>>;
host <<hostname assigned to probe>> {
    option dhcp-client-identifier "RIPE-Atlas-Probe-<probe-id>";
    fixed-address <<IP address assigned to probe>>;

How much bandwidth will the probe consume?

That depends on the number of measurements the probe is running at any given time. Experience shows that an IPv4-only probe uses approximately 4 Kb/s, an IPv4+IPv6 probe uses approximately 6 kb/s with some user-defined measurements assigned to it. The more UDMs your probe executes, the higher the bandwidth usage will be.

Hosts can also specify the maximum bandwidth their probe can use on their probe's detailed information page. We take these values into account when scheduling measurements, but we cannot promise that we'll never go beyond these limits, as we cannot always predict how much traffic a particular measurement will cause. You can always check your probe's bandwidth usage on the probe's detailed information page.

Why did you originally choose a hardware solution instead of software?

With a pure software solution, distribution costs are low and the number of potential hosts is very large. However, there are several significant downsides to a pure software approach:

  • Host machines may not run continuously over long periods, which affects our ability to gather round-the-clock measurements.
  • Measurements can be influenced by sharing systems and network resources with other applications on the host computer.
  • It is often not possible to install software like this in a corporate or computer centre environment.
  • It is easier to tamper with the results. This is also why we originally chose not to release a software version in tandem with the hardware solution.

Because of these drawbacks, we opted to develop the RIPE Atlas probe as a stand-alone piece of hardware. However, in late 2019 in addition to the hardware probes we started testing "software probes", the deployable software package version. This part of the service was fully enabled in 2020.

What hardware and software do you use?

The hardware of the first and second generation probes is a Lantronix XPort Pro module with custom powering and housing built around it. The third generation probe is a modified TP-Link wireless router (model TL-MR 3020) with a small USB thumb drive in it; this probe does not support WiFi (see below). The fourth generation is based on the NanoPI NEO Plus2 model. All versions of the probe perform the same built-in measurements, and except for the v1-v2 models, they are capable of doing the same measurements.

The probe is not a powerful device on its own, but it's small and attractive. The software on the device is developed by the RIPE NCC. The probes are connected to a hierarchical control and data collection service, which is also built by us.

So which services do I need for my probe to work?

The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas. The more kinds of outgoing traffic you allow, the more measurements will have a chance of succeeding. So please, at a minimum, also permit outgoing ICMP, UDP (DNS + traceroute + NTP) and TCP for traceroute and HTTP(S). Permitting outgoing DNS to any server is a must in order to be useful for non-local-resolver queries.

For incoming traffic: the probes don't provide real accessible services, so incoming ICMP/ping and UDP/traceroute should be enough.

What do the lights on the side of the probe mean?

The first and second generation probes have blinking LEDs (next to the Ethernet connector) when they are connected.

The third generation probe has a series of LEDs on its top side. When the probe is connected and functioning normally, the first, third and fourth LEDs are lit up. For a more detailed breakdown of what the different LEDs mean, please see the table below.

Status 1 (power) 2 3 4 5 (button)
Running from built-in flash on slow blink off off undetermined
Network test failed on off fast blink off off
Network test on off slow blink off off
Device booting on off off off fast blink
Connecting on off on blink off
Connected on off on on undetermined

Version 4 has the usual Ethernet traffic indicator leds on the connector itself.

Does my probe support WiFi?

Probes version 1 and 2 do not have any WiFi capabilities. Probe version 3 and 4 have WiFi hardware, however, in configuring the probe, we decided not to provide software to support WiFi for the probe because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy.

There's a switch on the side of my probe. What does it do?

Probe version 3 (TP-Link) has a switch on the side that is related to the TP-Link's capabilities as a router; however, this link has no function in relation to the device's role as a RIPE Atlas probe and its position does not affect the probe.

Does the probe work behind a NAT? I just want to plug it in at home and not configure anything.

Yes. The probe works fine behind a NAT box. So in most cases, one can just plug it in and it should "just work".

Can you connect my probe to a gigabit-only port?

The v1-v3 probes support only 10 Mbit/s and 100 Mbit/s. Version 4 probes support 10-100-1000 Mbit/s interfaces.

I have an IPv6-only network. Will the probe work on it?

Yes. All probes can be configured statically with an IPv6 address, default router, DNS resolvers, etc. through the web UI. In addition, version 3 and newer probes can be fully configured through router advertisements (support for RFC 6106 was added in firmware release 4680). There is at the moment no support for DHCPv6 (RFC 3315). Version 1 and 2 probes can obtain addresses and default routers through router advertisements, but cannot obtain DNS resolvers that way. For those probes, the DNS resolvers will have to be configured statically through the web UI.

Managing Your Probe

I connected the probe. Now what?

The probe will automatically connect to the RIPE Atlas infrastructure, most likely upgrade its firmware to the newest version (which take a few minutes) and begin performing predefined measurements. Once we see that the probe is connected, you'll be able to see your probe listed under the "My Probes" tab on the probes page when logged into the RIPE Atlas website. Your probe will also begin earning credits that you can use to perform your own user-defined measurements, which can provide valuable information about the performance of your own network. Find out more about user-defined measurements.

How do I access information about my probe and manage its settings?

You can get detailed information about your probe, including its connection history, built-in and user-defined measurements, firmware version, MAC address and much more on your probe's detailed information page. You can also manage different settings, such as setting a bandwidth limit, on this page. When you're logged in to the RIPE Atlas website, you can find your probe under the "My Probes" tab on the probes page. Just click on your probe to access the detailed information page.

How do you measure probe uptime?

A probe is "connected" when it has a working Internet connection and it is connected to the RIPE Atlas infrastructure. This means that if the probe has a working Internet connection, but it cannot connect to the central infrastructure (because it's firewalled or such) then it shows up as "disconnected". This is also the reason why one can see more connect/disconnect events than expected; even though the local network was working fine, there may have been a connection reset on the probe's connection to its controller.

Can I transfer a probe to a new host?

If you are hosting a probe and would like to transfer it to a new host (for instance, if you are leaving a company but a co-worker will take over responsibility for your probe), you can do so using the "Transfer Ownership" function on your probe's detailed information page (click on your probe, listed under the "My Probes" tab on the probes page when you're logged in to the RIPE Atlas website.

RIPE NCC members who host a probe and want to transfer it to a colleague will now see a suggested list of contacts in their LIR when transferring a probe.

In either case, you must be sure about this, because normally you won’t be able to reclaim your probe in case you transfer it to the wrong person.

Can I deploy a probe on someone else's network, such as my company's, for instance?

That's your decision, but in our opinion you must ask permission first.

Can I assign static IP addresses to my probe?

Yes. Please check the static network configuration documentation for details. Note that we recommend using static configuration only if dynamic configuration is otherwise not possible, since in many cases the static information can become stale, making the probe useless, without the probe host noticing this.

Can I disconnect my probe?

You can, but we'd like to ask you to keep it connected at all times if possible, even while you're on vacation. If you want to shut it down for good, then please return it to us so we can redistribute it to someone else. You can return unused probes to:

RIPE Atlas


Stationsplein 11

1012 AB Amsterdam

The Netherlands

Can I disassemble my probe to see what's inside?

No. You are not allowed to disassemble, reverse engineer, hack or otherwise harm your probe. If you still have questions about the probes after reading through the FAQ, let us know.

Can I / should I replace my older probe with a newer version?

There's generally no need to do this as long as the probe works. With the exception of v1-v2 probes which are more limited and only get security updates, the probes behave the same way so there's no reason to replace an older hardware just because it's not the latest.

You can apply for a new probe (or even consider running a software probe) if the hardware is not functioning any more and the resurrection steps don't help.

Managing Your Measurements

How do I use the RIPE Atlas network to perform my own measurements?

You can take advantage of the entire RIPE Atlas network to perform measurements about your own network(s). We call these user-defined measurements and you can find out more about how to set them up in the user-defined measurements documentation.

How do I stop a user-defined measurement?

You can see a list of your measurements under "My Atlas" and then "Measurements". You can stop one of your active user-defined measurements by clicking the stop button on the "general info" tab of the measurement details page. You can also select "archive", which means the measurement will be permanently removed from your measurements list.

Are there any special restrictions on HTTP measurements?

HTTP measurements are enabled for all users and from any probes. That said, the targets of HTTP measurements will only be RIPE Atlas anchors, which already run HTTP servers (you can learn more in the documentation, see a list and a map of current anchors, or find out how you can host one. The anchors only serve very small and well-defined pages, so this is not expected to cause bandwidth problems.

The RIPE NCC will support other, vetted HTTP measurements towards other targets as well, as long as it benefits the community, as well as other HTTP measurements that we deem operationally useful. These will be evaluated on a case-by-case basis.

What are measurements towards is a DNS zone for allowing RIPE Atlas measurements to target multiple destinations. Measurements that use this feature have the "resolve on probe" option turned on. Each time a probe executes a measurement, it does a DNS lookup for a name in this zone and the server gives an answer from a pre-defined list of IP addresses. Examples for this kind of measurements include "topology discovery" measurements (measurement IDs 5051, 5151, 6052 and 6152) that target one IP in each IPv4/IPv6 prefix routed on the Internet. At the moment RIPE Atlas administrators have the means to define such destinations, but we plan to let users use this feature too, if there's enough demand for it.

Security and Privacy

How secure is the system? Can someone take it over?

We've built in many safeguards to prevent anyone from taking over the system. For example, the probes don't have any open ports that one can connect to (even locally) - they only support outgoing connections. We also use mutual authentication between the probes and the infrastructure components. Of course, we cannot be absolutely certain that an attack could not be carried out. We believe that the limited capabilities and the obscurity of the individual probes make the system an unattractive target, and that the current protection mechanisms are adequate. You can find more information on our security page.

Are the locations of probes made public?

Locations of all probes, whether they are marked as public or not, are irreversibly obfuscated to up to one kilometre away. When viewing your own probe's page, the real location will be displayed. Note: coordinates obtained via the REST API are always obfuscated, even if you are identified as a probe host.

Does the probe listen to my local, private traffic?

No, it doesn't. It only talks to our central infrastructure and executes active measurement commands towards the public Internet.

If you're still concerned about the probe being able to snoop, you can install it on a switch port (the home router often has this already), where it cannot hear any other traffic. Even better, you can put it behind a firewall, as long as that firewall does not prevent the probe from talking to the outside world.

Will my IP address show up in measurements done by my probe?

Yes, it will, although personal information such as MAC addresses and email addresses will never be shown (although IPv6 addresses can also expose the MAC address). You can find out more about exactly what information is accessible for both probes marked public and those not marked public, in this detailed RIPE Labs article.

Do you accept any liability for incorrect operation, disputed actions or damages caused by the probe?

Sorry, we can't do that.

What information is visible to different users?

Different information is available for different RIPE Atlas users, including hosts, sponsors and the general public:

  • Hosts can see all available information about their own probes, including their probe ID, their network and other configuration settings, and their uptime information.
  • Sponsors cannot see the email addresses of the hosts whose probes they sponsor, or the network configuration settings, but can see all other information about the probes they sponsor.
  • The public can see some information about the public probes in the RIPE Atlas network, including probe IDs, connection history and user-defined measurements; however, the public cannot see configuration settings, MAC addresses, DNS entries or email addresses.

Is the measurement data made public?

RIPE Atlas probes collect data from two types of measurements: built-in measurements and user-defined measurements. Data from the built-in measurements is made publicly available. When RIPE Atlas users create their own user-defined measurements using the API, it is possible to create non-public measurements; however, all user-defined measurements created using the web interface are public measurements. It is also possible to switch existing measurements from “non-public” to “public” using the web interface, but not vice versa.

We want to encourage our users to make their measurements public because openly available data adds the greatest value to everyone taking part in RIPE Atlas, and sharing information is at the heart of such collaborative efforts. You can learn more about this issue in this RIPE Labs article.

User Interface

I only host a probe or two, but I can see a lot of probes in the list. Why?

Anyone can look at the state and measurement results of public probes in the RIPE Atlas network. You can see these probes listed on the probes page. When you're logged into the RIPE Atlas website, this list will also include a tab called "My Probes" that lists the probes you personally host.

How can I embed the graphs from my probe's page in my own webpage?

You need to embed a RIPEstat widget. See a practical example.


The probe is plugged in but is listed as "disconnected".

(For more help with this issue, see the documentation on troubleshooting probe issues.)

There could be several reasons for this. If you have a version 3 probe (white modified TP-Link router with a USB stick), your probe may have a problem with filesystem corruption. Please first try this simple procedure:

  • Unplug the probe from its power source
  • Remove the USB stick from the probe
  • Plug in the probe WITHOUT the USB stick
  • Wait for ten minutes
  • Insert the USB stick

Note that this must be done on a network with working DHCP; it will NOT work if you have configured your probe to use a static IP address. If you have configured your probe to use a static IP address, the only thing you can do is move it to a network with working DHCP.

If, after an hour, your probe is still listed as disconnected, you may need to replace the USB stick with another one:

  • Unplug the probe from its power source
  • Remove the current USB stick from the probe
  • Plug in a new, brand-name USB stick that is at least 4GB in size (it does not need any preparation but its contents will be erased so make sure it does not store anything crucial)
  • Plug in the probe
  • Wait at least 30 minutes for the probe to initialise the drive and upgrade its firmware

You can also click on the "Status" tab on your probe's detailed information page. You may be able to find more detailed information about a possible problem there, along with advice on how to fix it. (You can see your probe's detailed information page by logging in to RIPE Atlas, going to "My Atlas" and clicking on your probe's ID number.)

For a more detailed explanation of how to re-initialise the probe, please see this RIPE Labs article.

The probe doesn't have any lights on. Is it dead?

Once you connect the probe on both connections (Ethernet and USB), it should come alive quickly. The green "link" LED should come on when the Ethernet link is established. The orange "data" LED will blink as the probe sends and receives packets. If this is not the case then please make sure that both connections are fine (for example, the USB really gives power, the Ethernet port is active, etc.). If the probe still looks dead, please contact us.

I just connected my probe and the lights are up, but it is still listed as "disconnected" on the list of public probes. What is happening?

When you plug in the probe, it will take some time before enough data is collected and the probe is listed as connected. If this is the first time you plug in your probe (or it was disconnected for a long time), it's possible that it will immediately upgrade its firmware, which can take longer. Please check back in several hours.

The lights are on but I still cannot register my probe, or the system says my probe is not connected ("never seen"). What can I do?

Please double check that your probe received an IP address and DNS information through DHCP, and that there's no firewall rule or MAC address filtering blocking its access to the Internet.

I want to share my Internet connection of my Mac (Mini, iMac, MacBook, etc.) and run the probe on that, but it doesn't seem to work. What can I do?

Some RIPE Atlas users who use "Internet Sharing" of OS X (10.4 and 10.5) have reported these issues. A workaround, that seems to work in all cases that we know of, is to change reply_threshold_seconds to 0. See these links for more details:

I see 100% packet loss on all my probes to Is this expected?

Since early 2012, ICMP rate limiting has been enforced near RIPE Labs, leading to these ping results. Soon after this we discontinued this measurement.

We develop RIPE Atlas in cooperation with the Internet community, and we want to know what you think. Find out how to get in touch.