Hi everyone, can anyone explain to me the reason of system tags not being set (for long time)? There are system tags for every case, but there's also the case, that no tag is being set. For example: ipv6-works check (three possible cases): 1. tagged: system-ipv6-works 2. tagged: system-ipv6-doesnt-work 3. untagged (none of the above tags is set) I don't see the purpose of the untagged status. Either IPv6 / IPv4 works, or not. What is the completely untagged status supposed to tell me? The same applies to DNS checks. There's a tag for every case, plus the "no-tag status": DNS resolving check: 1. tagged: system-resolves-a-correctly 2. tagged: system-resolves-a-incorrectly 3. tagged: system-doesnt-resolve-a 4. untagged (none of the above tags is set) I would like to know the condition, how the controllers (?) decide this. Or in other terms: if a system tag is removed (untagged) shouldn't this implicate, that the opposite system tag has to be applied immediately? This is not a matter of a short time period, completely untagged probes do exist for long time periods. Thanks & best regards, Simon
On Wed, 5 Mar 2025 at 13:22, Simon Brandt via ripe-atlas < ripe-atlas@ripe.net> wrote:
ipv6-works check (three possible cases):
1. tagged: system-ipv6-works 2. tagged: system-ipv6-doesnt-work 3. untagged (none of the above tags is set)
I don't see the purpose of the untagged status. Either IPv6 / IPv4 works, or not. What is the completely untagged status supposed to tell me?
A "doesnt-work" tag is applied if the probe returns results for (in this case) some IPv6 measurements, and all of those results indicate a failure to reach the targets. If, on the other hand, the probe has a problem submitting results to the controller, then we don't know whether it can or cannot reach IPv6 targets, so it doesn't get either tag. In general you can consider a probe with a "connected" status, but none of (ipv4-works, ipv6-doesnt-work, ipv4-works, ipv6-doesnt-work), as having a problem submitting results due to some other issue.
The same applies to DNS checks. There's a tag for every case, plus the "no-tag status":
DNS resolving check:
1. tagged: system-resolves-a-correctly 2. tagged: system-resolves-a-incorrectly 3. tagged: system-doesnt-resolve-a 4. untagged (none of the above tags is set)
Similar to above: 1. The DNS record returned is as expected 2. A DNS record is returned, but it is not the one expected 3. No DNS record could be returned 4. The relevant measurement results were not submitted
Hi Christopher, thanks for the explanation, this makes sense!
In general you can consider a probe with a "connected" status, but none of (ipv4-works, ipv6-doesnt-work, ipv4-works, ipv6-doesnt-work), as having a problem submitting results due to some other issue.
Can we have a system-tag for this case too, instead of leaving the probes untagged? For example: "IPv4 issue suspected" "IPv6 issue suspected" "connection issue suspected" (for DNS results not delivered) This would help to make the probe hosts aware of problems. Leaving probes untagged is a bit... vacuous. In addition, the explanation you've provided here should be included in the official Atlas documentation (i wasn't able to find anything). Thanks & best regards, Simon On 05.03.25 13:40, Christopher Amin wrote:
On Wed, 5 Mar 2025 at 13:22, Simon Brandt via ripe-atlas <ripe-atlas@ripe.net> wrote:
ipv6-works check (three possible cases):
1. tagged: system-ipv6-works 2. tagged: system-ipv6-doesnt-work 3. untagged (none of the above tags is set)
I don't see the purpose of the untagged status. Either IPv6 / IPv4 works, or not. What is the completely untagged status supposed to tell me?
A "doesnt-work" tag is applied if the probe returns results for (in this case) some IPv6 measurements, and all of those results indicate a failure to reach the targets. If, on the other hand, the probe has a problem submitting results to the controller, then we don't know whether it can or cannot reach IPv6 targets, so it doesn't get either tag. In general you can consider a probe with a "connected" status, but none of (ipv4-works, ipv6-doesnt-work, ipv4-works, ipv6-doesnt-work), as having a problem submitting results due to some other issue.
The same applies to DNS checks. There's a tag for every case, plus the "no-tag status":
DNS resolving check:
1. tagged: system-resolves-a-correctly 2. tagged: system-resolves-a-incorrectly 3. tagged: system-doesnt-resolve-a 4. untagged (none of the above tags is set)
Similar to above:
1. The DNS record returned is as expected 2. A DNS record is returned, but it is not the one expected 3. No DNS record could be returned 4. The relevant measurement results were not submitted
Hello,
In addition, the explanation you've provided here should be included in the official Atlas documentation (i wasn't able to find anything).
The documentation for system tags can be found here: https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags - of course we can add the details that are missing there. Regards, Robert
participants (3)
-
Christopher Amin -
ripe.net＠toppas.net -
Robert Kisteleki