# Probe Tags
RIPE Atlas probes may be tagged to indicate properties, capabilities, network topology or any other categorisation. There are two kinds of tags: user tags and system tags. Each tag consists of a human readable name, possibly including spaces, and a hyphenated "slug" which is used when interacting with the API.
You can search for probes with a particular combination of tags using the API - see the API documentation for details.
# User tags
User tags may be applied and removed by the probe host by going to the probes list (opens new window), selecting a probe and choosing "Edit". It is then possible to select from a list of commonly used tags, or create a custom tag. We periodically review custom tags so we can merge similar ones and suggest them to other users.
# System tags
The RIPE Atlas system periodically applies special tags to probes. These tags can be recognised through the following characteristics:
- Their human readable name begins with
system:, or they appear in the "System Tags" section on the probe page
- Their "slug", used for querying the API, begins with
It is impossible for a RIPE Atlas user, including probe hosts, to apply or remove a system tag, or to create a tag that begins with a "system" prefix.
Probes are re-assessed every four hours for each tag by inspecting certain baseline RIPE Atlas measurement results. The lookback period for this inspection is also four hours unless otherwise specified.
Several categories of system tags are assigned to probes:
# Protocols capability
These tags indicate that a probe has a configured network interface for the given IP protocol version. They do not imply that this network configuration is correct or provide any kind of indication of network connectivity.
- system: IPv4 Capable (
- system: IPv4 RFC1918 address is configured (
- system: IPv6 Capable (
- system: IPv6 ULA is configured (
# Basic connectivity
These tags indicate whether RIPE Atlas believes a probe works or does not work on IPv4 or IPv6. A probe is defined as working on a particular IP version if it has at least one successful ping result for any one of a selection of baseline targets. It defined as not working if it only returns failures.
If there are no results for one IP version, but there are results for the other version, then any existing tag for the first version will be removed. If for some reason there are no results from a probe, for example when it has been offline for a while, then the tags will not be added or removed.
The selection of measurement targets is diverse in that it includes anycast and unicast servers belonging to different organisations and with different purposes.
- system: IPv4 Works (
- system: IPv4 Doesn't Work (
- system: IPv6 Works (
- system: IPv6 Doesn't Work (
The measurements used for applying these tags are:
- IPv4 ping k.root-servers.net (opens new window)
- IPv4 ping i.root-servers.net (opens new window)
- IPv4 ping ping.ripe.net (opens new window)
- IPv6 ping k.root-servers.net (opens new window)
- IPv6 ping i.root-servers.net (opens new window)
- IPv6 ping ping.ripe.net (opens new window)
These tags indicate a level of stability and reliability beyond that signified by the "Capable" and "Works" tags (see above). For a probe to qualify for a Stable tag, it must have at least a 95% success rate for at least 95% of the time for the ICMP ping measurements that it performs. This means that occasional outages or connectivity problems are allowed so long as they are short and infrequent. The effects of widely unreliable or unreachable targets are controlled for by considering the success rate relative to measurements by other RIPE Atlas probes to the same targets.
The three time periods are one day, thirty days and ninety days. IPv4 and IPv6 are treated separately.
- system: IPv4 Stable 1d (
- system: IPv4 Stable 30d (
- system: IPv4 Stable 90d (
- system: IPv6 Stable 1d (
- system: IPv6 Stable 30d (
- system: IPv6 Stable 90d (
The measurements used for applying these tags are all the ping measurements performed on the particular probe.
# DNS resolution
These tags indicate whether a probe can resolve simple hostname records to the expected IP address. A probe is defined as being able to resolve correctly if there is at least one correct response from each of its local resolvers. It is considered unable to reliably resolve if at least one of its local resolvers only returns failures. It is considered to resolve incorrectly if there is at least one incorrect result for each queried A or AAAA record. The records used for these tests are delegated to various unrelated DNS servers.
If a probe submits any results from a local resolver where the name in the question section of the DNS request does not match the name in the answer section of the DNS reply in terms of upper/lower case (a 0x20 bit check (opens new window)), then it is tagged as mangling the cases and no other DNS tags will be applied.
- system: Resolves A Correctly (
- system: Resolves A Incorrectly (
- system: Doesn't Resolve A (
- system: Resolves AAAA Correctly (
- system: Resolves AAAA Incorrectly (
- system: Doesn't Resolve AAAA (
- system: Resolver Mangles Case (
The measurements used for applying these tags are:
- DNS "IN A www.ripe.net." (opens new window) (for A)
- DNS "IN A www.icann.org." (opens new window) (for A)
- DNS "IN A www.ietf.org." (opens new window) (for A)
- DNS "IN AAAA www.ripe.net." (opens new window) (for AAAA)
- DNS "IN AAAA www.icann.org." (opens new window) (for AAAA)
- DNS "IN AAAA www.ietf.org." (opens new window) (for AAAA)
- DNS "IN A WwW.rIpE.nEt." (opens new window) (for case mangling)
# Probe metadata
These tags are not based on measurement results. Instead, they reflect a probe's intrinsic properties, such as its version (v1-v5, software, etcand whether or not it is also a RIPE Atlas anchor (opens new window) and if so, is it virtual?
- system: V1 (
system-v1) ... system: V5 (
- system: software (
- system: Anchor (
- system: VM anchor (
- system: geoloc disputed (
system-geoloc-disputed) - the probe's geolocation has been flagged as potentially inaccurate
- system: geoloc confirmed (
system-geoloc-confirmed) - the probe's host confirmed the geolocation to be correct after a dispute