- ripe-atlas - mailman.ripe.net

Incorrect location of probe #6422
by Ponikierski, Grzegorz 07 May '19

07 May '19

Hi all! According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? Regards, Grzegorz

1 0

Communication with probes' owners
by Ponikierski, Grzegorz 02 May '19

02 May '19

Hi all! From time to time I find probes which has incorrect country in their description. For example #10333 supposed to be in US but from my measurements it looks like it is somewhere nearby Amsterdam. If something has 10ms RTT to target in Amsterdam, has hops with `nl-ams14a-ri1-ae8-0.aorta.net<https://stat.ripe.net/nl-ams14a-ri1-ae8-0.aorta.net>` description and has ASN for LibertyGlobal then this probe is rather in Europe. It takes some time to resolve such issue via RIPE team so maybe we can get a form to send direct and short message to probe owner to let him/her know that something is wrong with his/her probe and we ask for verification. What do you think about that? Regards, Grzegorz

9 13

Probes fluctuation
by Rami Al-Dalky 30 Apr '19

30 Apr '19

Hello, I am running a number of one-off measurements and all what I request is 200 probes. However, I see a fluctuation in the number of participating probes (sometimes I get 198 and sometimes as low as 175). Any idea what is the issue? Thanks a lot, Rami

4 3

All our atlas probes have reverted to DHCP
by Sebastian Wiesinger 24 Apr '19

24 Apr '19

Hi, all of our four atlas probes have reverted from their fixed network configuration to DHCP which is a shame because there is no DHCP at their present locations. Also this not the first time it happend. Can someone explain why this happens and how to prevent this? This wastes a lot of time and effort every time it happens. Regards Sebastian

2 1

Re: [atlas] contacing probe owner.
by Geert Jan de Groot 20 Apr '19

20 Apr '19

> Quite the opposite IMHO, understanding that the anticipated means of > communication will be email and that the email address of a probe's host > will be generic, eg. <ripe-atlas-probe-[number](a)atlas.ripe.net>, > redirecting all incoming emails to a final address. The redirection > would be configured via the portal then. Using an address as described above would allow enumeration attacks. If it would use a hash instead it would be safer. The hash for probe XXX would be obtainable via the portal, where you would need to look up probe's details anyway. Geert Jan

2 1

Measurement result issues for some RIPE Atlas anchors
by Philip Homburg 18 Apr '19

18 Apr '19

In April, we started investigating a strange traceroute result reported by one of the RIPE Atlas anchors. The conclusion of our investigation is that the probe upgrade process for the v3 anchor firmware has been leaving old measurement daemons running as well as starting new ones. This means that a gradually increasing number of measurements from the affected anchors have been performed multiple times more or less simultaneously. Because those processes were writing to the same file, this resulted in a lot of garbled results. Purely by chance, the weird result that triggered the investigation had the first part of one result and the last part of another result in a way that generated syntactically correct JSON. The net result is that for the last few months, measurements done by anchors may have resulted in multiple results at roughly the same time or no results because the results were rejected as invalid. For those who wish to check whether results for specific measurements were affected, the following links will direct you to lists of probe IDs for the affected anchors: https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-virtual&fi… (VM anchors) https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-v3-pc-engi… (v3 hardware anchors) We are working to resolve the issue and will keep you updated as and when we have more to report. We apologise for any inconvenience this might cause. Philip

1 0

DNS-over-TLS and DNS-over-HTTPS measurement
by Petr Špaček 10 Apr '19

10 Apr '19

Hello, could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? I had impression that DNS-over-TLS is already supported but now I cannot find it in the UI so I'm probably wrong. Thank you for information! -- Petr Špaček @ CZ.NIC

3 3

Scheduled RIPE Atlas maintenance 2019-04-10 09:00 UTC
by Chris Amin 10 Apr '19

10 Apr '19

Dear RIPE Atlas users, We are planning on making a behind-the-scenes change to the RIPE Atlas database tomorrow in order to make the system more robust. Measurements scheduled during this time may be either rejected or delayed. Probes will continue to carry out measurements as usual so there won't be a gap in scheduled measurement results. The window for the maintenance is 2019-04-10 09:00 UTC until 12:00 UTC. We hope that it will be quicker than this and will keep you updated. Kind regards, Chris Amin RIPE NCC

1 1

DNS measurements broken today?
by Stephane Bortzmeyer 05 Apr '19

05 Apr '19

It seems all DNS measurements (not just mine, checked on <https://atlas.ripe.net/measurements/?page=1#tab-dns> return only an empty array today... % curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/ []%

1 0

Responsive Probe Fluctuations
by Marcel Flores 05 Apr '19

05 Apr '19

Hi All, Noticed a funny little swing in probe responsiveness. It seems to have returned to normal, but was curious if anyone else had seen it. We do one-off measurement where we select all probes, usually the responsiveness rates look something like: 12743 Requested / 10147 Actually Participated (Taken from 18 March) But on 19 March we started seeing rates more like: 12914 Requested / 7852 Actually Participated Which continued until about 28 March, when it returned to about the previous levels: 12916 Requested / 9943 Actually Participated Something funny happen with the dispatching? Did anybody else see? -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> p: +1 310.593.6880 e: marcel.flores(a)verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

2 2