- ripe-atlas - mailman.ripe.net

Probe name rules
by Daniel AJ Sokolov 03 Jun '18

03 Jun '18

Hello, I would like to suggest a naming convention for probes that excludes names referring to features or networks which are not present/supported. For example, I see a probe that contains in its name a large network, although the probe is actually connected to competitor networks. (I assume the probe's host changed their ISP and forgot to update the probe's name.) Such naming is misleading for Atlas users, but also opens a can of worms in relation to trade mark law. Similarly, a prove with "IPv6" in its name that doesn't support IPv6 could be confusing. BR Daniel AJ

2 1

Probe #595 invalid location
by Ponikierski, Grzegorz 27 May '18

27 May '18

Hi! I cannot open page for probe #595 (question is why, it's private?) but from what I see this probe is marked as US probe: [cid:image001.jpg@01D3F5BB.36A72710] But AS 29422 is Finish ISP and when you check traceroute from this probe you will see that's for sure it's more Finland than US. Traceroute: 595 ----------------- 1 - 192.168.0.254 NA None NA 1.614ms 2 - 83.150.126.202 29422 None NBLNETWORKS-AS Nebula Oy, FI 15.026ms 3 - 188.117.15.250 29422 rtr1-te4-3.lau.hel.fi.nblnet.com NBLNETWORKS-AS Nebula Oy, FI 14.762ms <- Finland 4 - 80.239.132.5 1299 hls-b2-link.telia.net TELIANET Telia Carrier, SE 15.005ms <- Finland 5 - 80.91.245.214 1299 s-bb4-link.telia.net TELIANET Telia Carrier, SE 22.251ms <- Sweden 6 - 80.91.249.219 1299 s-b5-link.telia.net TELIANET Telia Carrier, SE 21.888ms 7 - 62.115.36.166 1299 akamai-ic-310810-s-b5.c.telia.net TELIANET Telia Carrier, SE 22.332ms <- Sweden 8 - 23.216.52.2 21342 a23-216-52-2.deploy.static.akamaitechnologies.com AKAMAI-ASN2, US 22.111ms Can you double check location of this probe? Regards, Grzegorz

1 0

Aggregator for TXT record
by Ponikierski, Grzegorz 24 May '18

24 May '18

Hi! I wanted to use Aggregator feature for DNS measurement but looks like it doesn't work with TXT record. Anybody has experience with this feature? Does Aggregator support TXT record? Regards, Grzegorz

1 0

New on RIPE Labs: Update on the RIPE Atlas Anchor VM pilot
by Alun Davies 14 May '18

14 May '18

Dear colleagues, We recently published an update on our pilot programme to assess the feasibility of introducing virtual machines to the pool of RIPE Atlas anchors. Read all about it in this RIPE Labs article from Robert Kisteleki: https://labs.ripe.net/Members/kistel/update-on-the-ripe-atlas-anchor-vm-pil… <https://labs.ripe.net/Members/kistel/update-on-the-ripe-atlas-anchor-vm-pil…> Best regards, Alun Davies RIPE NCC

1 0

Probe #33346 invalid location
by Ponikierski, Grzegorz 11 May '18

11 May '18

Hi! Found another probe assigned to incorrect country: https://atlas.ripe.net/probes/33346/#!tab-network Probe is located in Hong Kong but Atlas things it's China ;) Can you fix it? Regards, Grzegorz

1 0

Atlas #50012 handed over..
by Geert Jan de Groot 09 May '18

09 May '18

Hi, Lia just handed over probe 50012 (that's the new hardware version), and I plugged it into the AIS/AfriNIC network here in Dakar. Can you please make this probe "mine" so I can administer it? For the next few days, will try a few things (and please do so yourself!) My existing probe is 16233. Currently it is powered through the USB port of another device, I will try PoE later (it will switch to 100 mbit then). Currently it seems to do 1gbit. Will make notes and share with you. GJ

2 1

Probe #27786 invalid location
by Ponikierski, Grzegorz 07 May '18

07 May '18

Hi RIPE team! Probe #27786 is located UK but Atlas see it as US probe. It make measurements incorrect. Can you verify it? Regards, Grzegorz

2 1

Firmware version 4660
by BELLAFKIH hayat 07 May '18

07 May '18

Dear Atlas users I am using data collected by RIPE Atlas probes, I found data with a firmware *4660*, but I can't find definition of the structure related to this firmware here <https://atlas.ripe.net/docs/data_struct/> . Any help? Regards *Hayat BELLAFKIH*

2 1

Minor change in the API Participation Requests endpoint
by Agustin Formoso 03 May '18

03 May '18

Dear Atlas users, We're planning to roll-out a minor change in the API Participation Requests endpoint. We'll be changing the response that gets sent out when a Participation Request is submitted. Although minor, the change may break your code if you are making use of the response. Current response example: [35878] Future response example after roll-out: { 'request_ids': [35878] } We plan to put this change into production two weeks from now. For those who don't know what Participation Requests are, they allow you to add or remove probes from a pre-existing measurement. You can find more information in https://atlas.ripe.net/docs/api/v2/manual/participation_requests.html Regards — Agustín Formoso RIPE NCC

1 1

RIPE Atlas probe status issues
by Chris Amin 26 Apr '18

26 Apr '18

Dear RIPE Atlas users, There were various issues relating to the recorded status of RIPE Atlas probes over the weekend. This was brought to our attention by internal monitoring and information provided by users on the mailing list. Throughout this period most probes did actually remain connected to controllers, and measurement results were collected as normal. The side effects included: * the number of probes reported as connected by the system was lower than it should have been * the status (connected/disconnected) of many probes was incorrect * new measurements took longer than usual to start * fewer probes than usual were available for new measurements, leading in some cases to “no suitable” probes messages when trying to schedule new measurements * various system tags were incorrectly applied, including many probes being marked as having USB problems when this was not the case * temporary discrepancies with crediting/debiting of RIPE Atlas credits for the connected time of probes The issues were caused by a bug fix deployment at Friday 9AM UTC where a package was accidentally downgraded causing a regression to an old bug in the task handling of the central system. This bug caused a backlog of messages to build, slowing down or stopping the registering of various status messages in the system. Problems built up gradually as the backlog increased, until the root cause was identified on Sunday morning. The issue was then fixed and the system stabilized completely by about 10AM UTC. We have identified procedural and technical solutions that will stop this problem happening again, and are looking at ways to improve our monitoring of these kinds of issues. We apologise for any inconvenience or confusion caused by this event and would like to thank all of you who took the time to notify us of what you were seeing. Kind regards, Chris Amin RIPE NCC

2 1