- ripe-atlas - mailman.ripe.net

WARNING - was Re: Trying to measure Quad9 latency
by Robert Kisteleki 14 Aug '20

14 Aug '20

Dear All, The email below made it to the mailing list, but it seems it so had an attachment which contains a virus. It may be useful to say it explicitly: DO NOT OPEN THE ATTACHMENT Regards, Robert On 2020-08-12 09:09, ripe-atlas wrote: > Re: [atlas] Trying to measure Quad9 latency > > ripe-atlas > ripe-atlas-bounces(a)ripe.net > > [snip]

1 0

[Moderated]
by ripe-atlas 12 Aug '20

12 Aug '20

This message was removed from the archive because it contained malware.

1 0

Re: [atlas] [RIPE-NCC/ripe-atlas-software-probe] Software probes only connect to one controller? (#45)
by Chriztoffer Hansen 10 Aug '20

10 Aug '20

On Mon, 3 Aug 2020 at 12:14, Philip Homburg <notifications(a)github.com> wrote: > This is not an ideal place to discuss how atlas works. It would be better to use the atlas mailing list (https://lists.ripe.net/mailman/listinfo/ripe-atlas). > > In any case, we have 2 controllers for software probes. Those controllers are kept separate from controllers for hardware probes. We placed both controllers at Hetzner and unfortunately, Hetzner seems to have some issues recently (or at least more than I remember). Typically a controller handles about 500 probes, so it will take some time before we will get controllers in other places in the world. > > Quite a bit of atlas backend logic depends on probes having just one controller at a time, so this is unlikely to change soon. > > Sending probes to different controllers happens automatically, but it happens on a time scale of around 6 hours. It seems that the issue at Hetzner was less than 2 hours. However, with all controllers for software probes at Hetzner, a long failure at Hetzner would indeed impact all software probes. In this case, why not have the software probes set up with a fall-back RIPE Atlas Anchor (controller)? E.g. - Setup a list of 2 or more Anchors in a hierarchical order, - If the software probe cannot reach the primary Anchor for more than 10-20 minutes., fall-back to the next Anchor reachable, - Retest connectivity to all configured anchors every 6 hours, - Revert to use the first reachable anchor in the locally configured list (a hierarchical order). * The above idea assumes an Anchor being able to temp. handle more than the default ~500 probes per Anchor, plus co-location diversity of >= 2 providers and >= 3 anchors. -- Chriztoffer

2 1

Far remote probe 34512 offline but partially works
by ripe＠brite.cz 27 Jul '20

27 Jul '20

Hi team, I have probe 34512 in distant location [not able to have it checked physically for some more time], it shows offline since 2020-07-21, no SOS messages listed since 2020-05-16. But other devices connected to the same router do work online, and also the router keeps sending me Log Messages via internet so its internet connection has to be working fine. Router log shows DHCP request getting from the Probe every 12 hours, as usually: 2020/07/27 18:51:44 Info 93-153-42-167.customers.tmcz.cz daemon dnsmasq-dhcp DHCPACK(eth1) 192.168.222.220 c0:25:e9:a8:57:96 2020/07/27 18:51:44 Info 93-153-42-167.customers.tmcz.cz daemon dnsmasq-dhcp DHCPREQUEST(eth1) 192.168.222.220 c0:25:e9:a8:57:96 The router itself is behind NAT and I'm not able to remote to it and proceed with further investigation. From the Log above I see the Probe is running and keeps requesting DHCP requests as usually, so not sure how it could show offline. Do you have any further logs or a way how to try to resurrect the Probe remotely? Thank you Jiri

1 0

Anyone with some spare credits for my experiments?
by JJ de Ronde 13 Jul '20

13 Jul '20

10 10

Issue in rendering built in graphs
by Anurag Bhatia 08 Jul '20

08 Jul '20

Hello Seems like something broken at the RIPE backend. Unable to render built-in graphs. I am getting this on any of the probes I check: URL: https://atlas.ripe.net/probes/17011/#!tab-builtins [image: Screenshot 2020-07-07 at 10.30.24 PM.png] Anyone with an idea on what's going around? -- Anurag Bhatia anuragbhatia.com

2 3

probe offline/lock up
by Bryan Fields 06 Jul '20

06 Jul '20

I had an interesting alert yesterday, as my probe 54858 said it was offline. I was unable to ping it from the router port it's directly connected to, but did some some traffic on the port via the counters. There was a fresh ARP entry as well. I power cycled it and it came back online. I was then able to ping it via v4 after it DHCP'd it's address. v6 pings were working to it's SLAAC address too. It has not gone offline now, but I am noticing pings on v4 are not working at all again. v6 seems unaffected. Is this normal or is there a problem with my probe? I've never really taken this close of a look before, I'm unsure if it has an issue or if this is normal. Thanks, -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

2 2

Ripe atlas: Fetch all probes data
by Niraj Sorathiya 29 Jun '20

29 Jun '20

Hello Team, Is there any way to fetch all probes data at once using "ripe.atlat.coustea" python API instead downloading dump provided by Ripe team ? Thank you ! Regards, Niraj

2 3

retrieve past measurements
by Fabiano D'Agostino 29 Jun '20

29 Jun '20

Good evening, I am trying to retrieve streaming data as described in the guide here: https://atlas.ripe.net/docs/result-streaming/ I was able to retrieve the measurement results using stream_type="result", but when I try to retrieve past measurements with the startTime flag it is not working. How can I solve? Thanks in advance, Fabiano

1 0

New on RIPE Labs: Measuring IP Connectivity with RIPE Atlas
by Mirjam Kuehne 26 Jun '20

26 Jun '20

Dear colleagues, During a hackathon Branimir Petricevi and his colleagues at Leaseweb wanted to measure network performance that most accurately simulates a customer's experience with a network. They used RIPE Atlas to do that. Find out more in this new RIPE Labs article: https://labs.ripe.net/Members/branimir_petricevic/measuring-ip-connectivity… Kind regards, Mirjam Kühne RIPE NCC

3 2

Unauthorised probe transfers
by Paul Eagles 24 Jun '20

24 Jun '20

Hello, I've just had 2 emails saying that 2 of my software probes (numbers 1000305 & 1000137) have been transferred to LeaseWeb NOC. Both these probes (and another) live on LeaseWeb VPSs (one in NL, one in USA) but I haven't started or authorised a transfer. Before I go and shout at then, how could this have happened? Checking in 'My Atlas' it does indeed no longer show these as being my problems. Why would the good people at RIPE allow transfer of 2 of my probes without my approval? Yours, Paul.

4 6

Who wants 52.4M credits?
by Paul Eagles 24 Jun '20

24 Jun '20

I've got 52.4M credits that I don't need. Does anyone want them? Cheers, Paul.

3 2

dead v1 probe
by Gert Doering 22 Jun '20

22 Jun '20

Hi, have there been software updates for v1 probes recently? I've heard about a few v1 probes that have died "just last week" - mine among them (#461), fell off the net with "Firewall Problems Suspected", but it's no longer even ARPing properly (= either it totally lost its config and wants DHCP now, which there isn't in this network, or it just died)... So knowing whether this is a more widespread issue and possible reasons would help me to decide how much effort to invest in debugging this. gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

10 12

RIPE Atlas Software Probes
by Philip Homburg 22 Jun '20

22 Jun '20

Dear colleagues, We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas. For more details, see our new article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes Kind regards, Philip

18 37

Notifications
by Thomas Schäfer 18 Jun '20

18 Jun '20

Hello, is there a possibility to get notified if the probe has lost IPv6 connectivity? At the moment it seems to me, notification only works if the connection is down with both protocols. Regards, Thomas

5 5

Q/ if Id 2303 works as expected?
by Schaefer, Henry 11 Jun '20

11 Jun '20

Hi RIPE-Atlas team, my ripe probe 2303 shows as being up and running, it is connected in a NAT environment. The probe does not show data for the Built-Ins (e.g. No data available for 2303 / 1009 for this time period) as well as is not participating in measurements. Can you check/confirm that it is not broken or advise what I would need to do to make it work like other probes please? Thanks & Regards Henry Schaefer. [image: Verizon Business Ready] <http://www.verizon.com/business> Henry Schaefer Verizon Business Markets Elisabethstraße 29-31 12247 Berlin, Germany O +49 (0)30.7669.1525 | M +49.173.262.8459 henry.schaefer(a)de.verizon.com [image: Facebook] <http://www.facebook.com/verizon> [image: Twitter] <http://twitter.com/verizon> [image: Instagram] <http://www.instagram.com/verizon> ====================================================================== Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsgericht Dortmund, HRB 14952 - Geschäftsführer: Detlef Eppig - Vorsitzender des Aufsichtsrats: Francesco de Maio

1 0

Turris SW probe - long time to connect
by Jan Pavlinec 04 Jun '20

04 Jun '20

Hello, Since this week based on report [1], [2] from Martin we were able to observe his issue, which he reported and by using Atlas SW Probe 5010 and older, we noticed that in CLI probe is running and that it is doing something, but on the RIPE website, it shows that probe is disconnected. Can you please check probes IDs (1000585, 1000243) and what it took so long to show that it is connected? Both of those probes were shown as connected at the same time - 20:22) on Tuesday? We noticed that in some cases if you were using the latest version 5020 and register a new probe, it is working within a few minutes. However, we pushed to all our Turris OS version updated Atlas SW Probe to version 5020 and some of our users noticed similar maybe the same behavior. A probe was running on the router, but it was disconnected for almost an hour (probe ID 1000036) The router is working in all cases, ping, dig connection is OK. I'm wondering if this issue isn't on server side. In reg_init_reply.txt were following data: WAIT TIMEOUT 115 Do you know how to debug it more? [1] https://forum.turris.cz/t/turris-os-5-0-0-is-released-in-hbt/12733/149 [2] https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/38 Looking forward to hearing from you, Jan

1 0

Feature request DNS DoH measurement
by Yang Yu 25 May '20

25 May '20

Hi, As DoH is getting more adoption, it would be interesting to have DoH query support on Atlas. With support added as an additional protocol for DNS measurement (currently TCP/UDP), most measurement creation/result parsing settings can be reused. Yang

3 3

anchor on a /32 network with on-link routing ?
by Matthieu Herrb 24 May '20

24 May '20

Hi, here at Tetaneutral.net we purchased an anchor with the idea to host it in our network. For IPv4 We are using /32 addresses everywhere, and do the routing by setting the 'on-link' flag on the default route. This configuration doesn't seem to be possible through the management interface. It complains that the gateway is not no the same network as the host and provides no way (as far as I can tell) to setup the 'on-link' flag. Apart from inserting another router in front of our anchor to let it use a narrower prefix, is there a way to set it up ? Or can this be considered for the future evolutions of the anchor software ? Thanks in advance. -- Matthieu Herrb

1 0

Looking for RIPE Atlas credits
by Nils Rodday 21 May '20

21 May '20

Dear RIPE Atlas users, As I have been using around 300M credits over the past few months and am close to running out, I would like to ask if somebody has some spare credits to transfer into my account: nils.rodday(a)unibw.de I am a PhD-student at the Bundeswehr University Munich & University of Twente. If you have credits to share, I would appreciate it. Thanks. :) Kind regards, Nils

15 23

running a probe via LTE access
by Thomas Schäfer 21 May '20

21 May '20

Hi, Has anybody experience with running a probe via LTE? I see only a little amount if I use the tags 4g or LTE, together with IPv6 as requirement, just less than 10. What is the monthly data volume you have? Is it a big problem if I run in a speed limit of 32kbit/s? Regards, Thomas

5 5

One of my hosted probes don't accept measurements
by Evgeniy S. 07 May '20

07 May '20

Dear RIPE guys, one of probes hosted by us https://atlas.ripe.net/probes/35439/ shows as connected and good to go, but when I create any measurements with this ID I see "1 Requested / None yet Actually Participating" Please advice what's wrong with it and how to troubleshoot? -- With regards, Eugene Sudyr

2 4

status-check redirects to itself?
by Stephane Bortzmeyer 30 Apr '20

30 Apr '20

Since today, status-check seems to redirect to itself? % curl -v https://atlas.ripe.net/api/v2/measurements/2060427/status-check\?permitted_… ... < HTTP/1.1 301 Moved Permanently < Server: nginx/1.16.1 < Date: Wed, 29 Apr 2020 17:57:17 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 0 < Connection: keep-alive < Location: /api/v2/measurements/2060427/status-check/?permitted_total_alerts=3 What's up?

5 5

Setting the DNS AD bit
by Stephane Bortzmeyer 15 Apr '20

15 Apr '20

It seems there is currently no way to set the AD bit in DNS queries? (Through the API, we can only control RD, CD and DO bits.)

2 1

Online hackathon: Internet Health Measurements & COVID-19
by Vesna Manojlovic 08 Apr '20

08 Apr '20

Dear all, just like many other organisations, RIPE NCC is having a COVID-19 focused hackathon with very broad goal: measuring Internet health, while focusing on RIPE Atlas, RIS & OONI data. In the third week of our online event, we have a very open, very lose collective: no registration, no prizes, no deadlines... Our results are currently mostly data-visualizations & analysis: https://labs.ripe.net/covid19 To join: * read about active projects on EtherPad, and contribute: https://pad.riseup.net/p/ripe-ncc-corona-hackathon-keep * join Jitsi for video conferencing: https://jitsi.hamburg.freifunk.net/WiseGeeseUniteCarefully * chat here: slack.ooni.org / #oon-dev (also bridged to IRC) Incremental reports are added to this article: https://labs.ripe.net/Members/becha/hackathons-in-the-time-of-corona Our next call will be on Tuesday 14. April at 11:30 AM CEST (on Jitsi) If you'd like to join one of the many other hackathons, look here: https://wiki.techinc.nl/User:Becha/COVID-19#Hackathons Stay safe, stay @ home, stay healthy... Kind regards, Vesna

1 0

No Atlas today: bad gateway
by Stephane Bortzmeyer 31 Mar '20

31 Mar '20

https://atlas.ripe.net/ 502 Bad Gateway nginx/1.16.1 COVID-19 on the server?

5 6

Re: [atlas] Probe 2285 is disconnected (Randy/Bainbridge Comcast)
by Randy Bush 21 Mar '20

21 Mar '20

i keep getting these > Your probe 2285 has been disconnected from the RIPE Atlas > infrastructure since 2020-03-18 06:43:44 UTC. status shows it down but i can ping6 the probe, and from the local gateway, i can ping4 it's natted address psg.com:/usr/home/randy> ping6 2601:600:c680:2fe:220:4aff:fee0:246d PING6(56=40+8+8 bytes) 2001:418:1::62 --> 2601:600:c680:2fe:220:4aff:fee0:246d 16 bytes from 2601:600:c680:2fe:220:4aff:fee0:246d, icmp_seq=0 hlim=56 time=13.533 ms 16 bytes from 2601:600:c680:2fe:220:4aff:fee0:246d, icmp_seq=1 hlim=56 time=12.370 ms root@wrt-biwa:~# ping 192.168.0.27 PING 192.168.0.27 (192.168.0.27): 56 data bytes 64 bytes from 192.168.0.27: seq=0 ttl=64 time=0.921 ms 64 bytes from 192.168.0.27: seq=1 ttl=64 time=0.701 ms network tab shows a long history of very short disconnects there is a strat 1 sitting on the same lan, and a lot of chimers out in the world think the strat 1 is preferred. no, that is not a definitive test in any way, but it's all i can think of at my current caffeine level. comcast? modem? v1 probe? how to better diagnose? randy

2 2

Cross-connecting Communities : hackathon about the Internet health
by Vesna Manojlovic 20 Mar '20

20 Mar '20

Dear colleagues, please join our virtual hackathon: https://labs.ripe.net/Members/becha/hackathons-in-the-time-of-corona Regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

Probe 2177 disconnected since Tuesday
by Werner Wiethege 20 Mar '20

20 Mar '20

The green light is on and the orange light flashes but I don't see any network traffic from it. The port LED on the switch lights up when the cable is plugged in. I have disconnected it and plugged it in again after a few hours but that didn't change anything. Werner

4 7

Software probe using port 8080
by Paul Eagles 13 Mar '20

13 Mar '20

Hi, Is there any way to change the ports that the software probes use? Port 8080 is used by the probe which conflicts with another piece of software I wanted to use. Looking in the processes I saw this: atlas 843 0.0 0.2 50348 5992 ? S 10:15 0:00 /usr/bin/ssh -o ServerAliveInterval 60 -o StrictHostKeyChecking yes -o UserKnownHostsFile /var/atlas-probe/.ssh/known_hosts -R 50948:127.0.0.1:2023 -L 8080:127.0.0.1:8080 -i /var/atlas-probe/etc/probe_key -p 443 atlas(a)ctr-fsn01.atlas.ripe.net KEEP I had to kill the PID in order to run the other software I need so at present this new software probe is down. I'd like to start it up again but can't unless I can control which port the SSH tunnel is using. Thanks, Pauil.

3 3

Software probes offline since updating to 5010-3
by Paul Eagles 12 Mar '20

12 Mar '20

Hi all, About an hour ago I updated my 4 software probes (1000136, 1000137, 1000149 & 1000177) to 5010-3 from 5010-1 and they're all still showing as offline. For each probe I went through and updated the keys within a minute or so of the installation finishing so I don't think that's the problem. It shouldn't be an internet connection issue, they're all using the same connection as they were prior to the update and prior to the update all 4 probes were connected OK. Plus I have a physical probe at home in the same location as one of the software probes and that physical probe is showing as online. One of the software probes has been rebooted but that didn't seem to make any difference. Checking the running processes on the host everything appears OK, I see 2 instances of the ATLAS binary running. Am I missing something or just being impatient? Cheers, Paul.

2 2

(not) disconnected probes
by Romain Fontugne 11 Mar '20

11 Mar '20

Hi, I found that the following probes are reported disconnected for several hours a day, more or less at the same time, but all their built-in measurements are there and seem normal: https://atlas.ripe.net/probes/32639/#!tab-network https://atlas.ripe.net/probes/28818/#!tab-network https://atlas.ripe.net/probes/19107/#!tab-network https://atlas.ripe.net/probes/14831/#!tab-network https://atlas.ripe.net/probes/11982/#!tab-network These probes are in different ISPs and locations in Japan. Any idea why this is happening? something funky on the controllers side? Thanks, Romain

2 4

New on RIPE Labs: What’s the Deal with IPv6 Link-Local Addresses?
by Philip Homburg 11 Mar '20

11 Mar '20

Dear colleagues, Stephen Strowes, Emile Aben and I published a new article on RIPE Labs on how link-local addresses in IPv6, and specifically the '%eth0'-part of link-local addresses, can have an impact on RIPE Atlas measurements. https://labs.ripe.net/Members/philip_homburg/whats-the-deal-with-ipv6-link-… We think this will be an interesting read for network operators and others who are using RIPE Atlas measurement data or are interested in IPv6. Kind regards, Philip Homburg RIPE NCC

1 0

Broken traffic graphs in latest firmware (5010)
by Philip Homburg 10 Mar '20

10 Mar '20

Hi, A change in the RIPE Atlas probe code to make reporting traffic statistics optional in software probes (and disabled by default) has the unfortunate side-effect that reporting of traffic statistics is now disabled on Version 3 and Version 4 hardware probes, as well as all anchors. This change was rolled out in firmware version 5010. Unfortunately, this effect was not spotted during testing. We will roll out a new firmware release that corrects this issue in coming weeks. Philip

1 0

Reg query of code
by Adarsh Pandey 24 Feb '20

24 Feb '20

Dear Team Can we get the code of ripe atlas server Regards ADARSH PANDEY NKN

2 1

check dns64/nat64 behavior ?
by Thomas Schäfer 21 Feb '20

21 Feb '20

Hi, is there a simple way to check the reachability of IPv6 targets by probes behind NAT64? e.g. If I try to ping www.t-online.de with Adress Family IPv6 I get immediately the error " No IPv6 address found for target" instead of "measuremnet created". Same problem exists for DNS measurements. Regards, thomas

2 2

Probes were incorrectly not tagged with the stability tags
by Chris Amin 21 Feb '20

21 Feb '20

Dear colleagues, Over the past month there have been issues with the "system-ipv[45]-stable-{1,30,90}d" tags, which were not applied to many of the probes that should have had them. This was caused by accidental data format changes from a backend migration. The issue should now be fixed, so probes will have the correct tags applied. If you notice any persisting issues then please let us know! Apologies for any inconvenience. Kind regards, Chris

2 2

atlas probe down
by MAYER Hans 19 Feb '20

19 Feb '20

Dear All, Our Atlas probe with ID 35603 is down since Wednesday exactly 12:00 LT. I unplugged power and powered on, but no success. After power on some LED's are blinking. Finally the power LED stays on and the LED next to it is blinking. But I can't ping this probe. Either on IPv4 nor on IPv6. We got this probe in summer 2018. So I can't believe it's EOL. Any ideas what I can do ? Kind regards Hans --

2 2

Can I issue a traceroute measurement with multiple targets?
by Vasileios Giotsas 11 Feb '20

11 Feb '20

If I have 100 IPs to target from a single probe, is it possible to create a single measurement with 100 targets similar to how I'd do if I wanted to target a single IP from 100 probes? I've read through the Atlas API documentation and couldn't find anything like that but it looks like some of the built-in measurements do that. Thanks, Vasilis

2 2

Atlas API stream broken?
by Teun Vink 10 Feb '20

10 Feb '20

Hi, Since ~13.30h CET this afternoon our Atlas data stream subscriptions (using the ripe.atlas.cousteau python library) stopped receiving updates. Earlier today we (at 11.27h) observed some issues with the backend where we received redis errors, which were resolved at ~12.09h CET. I heard these were related to some firewall issues, could these problem be related? Regards, -- Teun Vink BIT | teun(a)bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

2 1

Graphs and measurements are scaled by a factor of 1000
by Enrico Ardizzoni 07 Feb '20

07 Feb '20

Starting from 06/02/2020 at 6.00 AM UTC all graphs and measurements are scaled by a factor of 1000. Something went wrong on probes backend... "An error occurred while retrieving measurement data. We apologise and do our best to fix it asap!" See: https://atlas.ripe.net/probes/249/#!tab-builtins https://atlas.ripe.net/probes/12120/#!tab-builtins E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara

2 3

Planned Atlas downtime on 29 January
by Robert Kisteleki 06 Feb '20

06 Feb '20

Dear RIPE Atlas users, Please be aware that we plan to do maintenance work in the RIPE Atlas core infrastructure two weeks from now, on Wednesday 29 January, between 9:00-12:00 CET (Amsterdam time). The RIPE Atlas website, UI and API will be unavailable in this period. The probes should remain connected and results will be collected normally, although during this period they can only be accessed real-time via the streaming service. Apologies for the inconvenience this may cause. Regards, Robert Kisteleki

2 3

Using Atlas for Monitoring of Anycast DNS
by Klaus Darilion 20 Jan '20

20 Jan '20

Hello! I want to restart this old thread and ask for available tools. For our Anycast DNS cloud, I want to measure the "performance", ie the RTT from Atlas probes. 1. Create measurements (I can do that already ;-) 2. Analyze this measurements: - fetch measurement - analyze the probe locations (ie. country, continent) - create reports with average RTT from certain countries and continents This second step I have partly in old scripts using influxdb and grafana dashboard - but that was a proof of concept with bad code. So, before starting coding from the base - are there some available scripts which can do the second part? Is https://github.com/RIPE-NCC/ripe.atlas.sagan still the way to go for measurement processing or are there meanwhile some better/smarter libraries? ie something for php? Thanks Klaus Am 20.11.2014 um 16:32 schrieb Klaus Darilion: > Hi! > > I want to monitor an Anycasted authoritative name server: > - are all nodes responding > - are all nodes in routing > ... > > > So I thought about starting a long term DNS measurement with plenty of > probes and NSID queried. Then, checking the results I should see every > possible NSID if there are for more probes than Anycast-nodes. > > Does anybody have done that (or similar) already and want to share code? > > Can the RIPE Atlas Status Checks be used for such monitoring? > > Thanks > Klaus >

4 4

Probe is offline but shown online
by Andre Heinrichs 19 Jan '20

19 Jan '20

I’ve just discovered my probe #29384 blinking frantically while the website claims it had been online for more than a day (which can’t be true as my DSL had to get a new connection with a different IP). I tried rebooting the probe but all that got me is lower values of Power-Up time in the SOS requests the probe sends every couple of minutes. From what I can guess it looks like something in RIPE ATLAS isn’t working right. Would be great if someone could have a look. TIA, Andre, Who’s trying to get some sleep now.

3 2

Probe stability tags
by Chris Amin 08 Jan '20

08 Jan '20

Dear RIPE Atlas users, Due to an error in our backend systems, the probe stability tags ("system: IPv4 Stable 30d" etc) had been gradually becoming stale over the past three months, meaning that probes were not gaining or losing these tags when they should. This has now been fixed, so probes are once again tagged appropriately. We have improved our internal monitoring so this kind of issue will be noticed more quickly next time. Apologies for any inconvenience caused. Kind regards, Chris Amin RIPE NCC

1 0

New RIPE Atlas Terms&Conditions
by Robert Kisteleki 08 Jan '20

08 Jan '20

Dear RIPE Atlas users, We'd like to inform you that a new version of the RIPE Atlas Terms & Conditions has just been published. Most changes in this version are needed for the introduction of "software probes". The new version (3.4) is available at https://atlas.ripe.net/legal/terms-conditions/ and will be effective as of 11 February 2020. Regards, Robert Kisteleki

1 0

Maintenance or incident?
by Stephane Bortzmeyer 07 Jan '20

07 Jan '20

% curl https://atlas.ripe.net/ curl: (7) Failed to connect to atlas.ripe.net port 443: Connection refused It started around 1015 UTC.

4 4

A new year's break for the probes
by Robert Kisteleki 03 Jan '20

03 Jan '20

Happy new year to all RIPE Atlas users! It seems we've given a little break to our probes so they can celebrate the new year too ... >From midnight 1 January until approximately noon 2 January there were no built-in measurements running. This is due to an overlooked fact where the built-in measurements had a pre-defined end date of 2020-01-01. The system dutifully observed this date and did not schedule these measurements any more. We fixed this setting on Thursday, 2 January and the system returned to normal operations shortly thereafter. As a consequence, there's a gap in the delivered measurement results for built-in measurements (i.e. IDs < 1 million). Results for the User-Defined Measurements were not affected. Please accept our apologies for the inconvenience this can cause. Regards, Robert Kisteleki

2 2

One-off measurements not terminating
by Steve Gibbard 30 Dec '19

30 Dec '19

Hi Atlas folks, I hope you’re having a good holiday season. Sorry to interrupt it by complaining about issues. On Christmas Eve my time (early Christmas morning your time) there was an Atlas issue where any attempt at reading measurements failed with an HTTP 500 status error. That appears to have gotten fixed on Christmas (a really big thank you to whoever worked on that) but since then it appears that while most of the one-off measurements we’ve created have delivered results very quickly, none of the measurements created since 17:00 UTC on 2019-12-25 have stopped running. As shown in the Atlas portal: 23722197 Traceroute www.globaltraceroute.com (AS13335) Test Traceroute 1 one-off 2019-12-25 22:24 Never 23722089 Traceroute archive.ubuntu.com (AS41231) Test Traceroute 1 one-off 2019-12-25 19:16 Never 23722088 Traceroute sps.prima.com.ar (AS10318) Test Traceroute 1 one-off 2019-12-25 19:14 Never 23721915 Traceroute www.globaltraceroute.com (AS13335) Test Traceroute 1 one-off 2019-12-25 17:00 Never And on for every measurement between then and now. Previously, the typical one-off measurement was listed with start and stop times less than 10 minutes apart. When a user has 100 measurements running concurrently, creation of new measurements fails, which is happening for me now. If somebody could take a look at this, I’d really appreciate it. Thanks, Steve

2 3

Deletion of erroneously scheduled measurements
by Nils Rodday 29 Dec '19

29 Dec '19

Dear Atlas folks, I have accidentially scheduled many faulty measurements via the API and am now looking for a way to remove them in order to minimize unnecessary burden on the Atlas system and not to pollute my account & limits with unnecessary measurements. However, the DELETE statement (AtlasStopRequest) only seems to be able to stop ongoing measurements [1]. I always get the following reply trying to remove any future measurement: {'error': {'detail': 'That measurement cannot be stopped', 'status': 400, 'title': 'Bad Request', 'code': 104}} Also, the AtlasChangeSource & AtlasChangeRequest of Cousteau [2] can only change ongoing experiments (as I wanted to set the probes in each measurement to 1 if I wasn´t allowed to delete any of them). But since they are upcoming, but not ongoing, I could also not alter them. I am also referring to a mailing-list post from October 2013 stating essentially the same problem [3]. Given the significant amount of time that has passed since then I wanted to raise this issue again. Is there any way to delete a measurement that is in the "SPECIFIED" state, which means that it will only be executed in the future? I understand that we might want to avoid deletion of measurements that have already been run in the past in order to allow others to benefit from the results, but why shouldn´t one be allowed to eliminate faulty measurements that have been scheduled by accident in the future? Thanks & a Happy New Year! Kind regards, Nils [1] https://atlas.ripe.net/docs/api/v2/manual/measurements/stop-measurements.ht… [2] https://ripe-atlas-cousteau.readthedocs.io/en/latest/use.html [3] https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-October/001058.html

1 0