But what is going on then with: https://atlas.ripe.net/frames/probes/1003690 This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected. Using a curl request to: stat.ripe.net/data/atlas-probes/data.json?resouce=15435 shows this probe, with a tag “is_public” : false and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects. How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”? Regards, Ernst J. Oud
You're right that the probe page is not shown, however the public details are available at https://atlas.ripe.net/api/v2/probes/1003690 The important point there is that the system has not granted the "system: IPv4 Works" tag, so is not available for IPv4 measurements. In general the scheduler doesn't know/care about a probe being marked as public or not. Can you confirm whether the same measurement request works for IPv6 (af=6) measurements? Note that if you schedule measurements together they must all be IPv6 in that case. In the meanwhile, we'll think about including the non-public probes (albeit with their somewhat restricted details) as part of a redesign of the probe page coming up soon. Cheers, Chris On 15/12/2022 13:12, Ernst J. Oud wrote:
But what is going on then with:
https://atlas.ripe.net/frames/probes/1003690 <https://atlas.ripe.net/frames/probes/1003690>
This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected.
Using a curl request to:
stat.ripe.net/data/atlas-probes/data.json?resouce=15435
shows this probe, with a tag “is_public” : false
and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects.
How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”?
Hi Chris, sorry for "stealing" this conversation, but it's interesting to hear that there will be a redesign of the probe page coming up soon. Can we have a discussion about that? There are several things, that bother me a bit... BR, Simon On 15.12.22 13:51, Chris Amin wrote:
You're right that the probe page is not shown, however the public details are available at https://atlas.ripe.net/api/v2/probes/1003690
The important point there is that the system has not granted the "system: IPv4 Works" tag, so is not available for IPv4 measurements. In general the scheduler doesn't know/care about a probe being marked as public or not.
Can you confirm whether the same measurement request works for IPv6 (af=6) measurements? Note that if you schedule measurements together they must all be IPv6 in that case.
In the meanwhile, we'll think about including the non-public probes (albeit with their somewhat restricted details) as part of a redesign of the probe page coming up soon.
Cheers, Chris
On 15/12/2022 13:12, Ernst J. Oud wrote:
But what is going on then with:
https://atlas.ripe.net/frames/probes/1003690 <https://atlas.ripe.net/frames/probes/1003690>
This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected.
Using a curl request to:
stat.ripe.net/data/atlas-probes/data.json?resouce=15435
shows this probe, with a tag “is_public” : false
and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects.
How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”?
On 2022-12-15 14:33, ripe.net@toppas.net wrote:
Hi Chris,
sorry for "stealing" this conversation, but it's interesting to hear that there will be a redesign of the probe page coming up soon. Can we have a discussion about that? There are several things, that bother me a bit...
BR, Simon
Hi, The team started thinking about how to improve these pages. We're using already collected user input, our own observations and including technical changes that are looming anyway. We're early in this work but are happy to take your input already :-) It can be a thread you start here (e.g. what do you like now? what do you dislike? what is missing? ... about probe pages) or in a "private interview" of some kind. Cheers, Robert
Hi Robert, here are some things that bothered me, when looking at the probe pages: 1. Network Tab: When a probe is connected via IPv4 and IPv6, the second IPv4 DNS resolver is not displayed on the probe page. If the Probe is connected via IPv4 only, both IPv4 resolvers are displayed. At least, that is what I have observed for my probes. 2. Network Tab: Connection Information: Instead of "Last Week" and "Last Month" it should be "Last 7 Days" and "Last 30 days". For example: in my understanding "last month" means time between 1. - 30. November since the current month is december. But the probe page counts the online-time of last 30 days. Maybe this is a regional thing... are there countries which differentiate between month and calendermonth? I would appreciate, if it would be X days instead of week and month, to avoid confusion. 3. General Tab: "Router Type" cannot be set for Anchors (at least for my two anchors). 4. Network Tab: Please take a look at these probes: https://atlas.ripe.net/probes/26320/#tab-network https://atlas.ripe.net/probes/1004823/#tab-network What is causing the probe page to display so much old IPv6 addresses? It doesn't matter of the probe is connected or not, this error can happen in both cases. I've opened a ticket for this two weeks ago (#536036), but got no response. 5. General Tab: Maybe provide a textfield where probe/anchor hosts can write some details. A description, public contact details or whatever. Thanks, Simon On 15.12.22 15:08, Robert Kisteleki wrote:
On 2022-12-15 14:33, ripe.net@toppas.net wrote:
Hi Chris,
sorry for "stealing" this conversation, but it's interesting to hear that there will be a redesign of the probe page coming up soon. Can we have a discussion about that? There are several things, that bother me a bit...
BR, Simon
Hi,
The team started thinking about how to improve these pages. We're using already collected user input, our own observations and including technical changes that are looming anyway.
We're early in this work but are happy to take your input already :-) It can be a thread you start here (e.g. what do you like now? what do you dislike? what is missing? ... about probe pages) or in a "private interview" of some kind.
Cheers, Robert
participants (4)
-
Chris Amin -
Ernst J. Oud -
ripe.net＠toppas.net -
Robert Kisteleki