From compyblog at gmail.com Sun Jul 1 02:21:48 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Sun, 1 Jul 2018 02:21:48 +0200 Subject: [atlas] Probe connection not holding Message-ID: Hi everyone, Another day, another weird effect. My probe (29384) keeps losing its connection to the Atlas systems. That seems to happen since the backend problems from Saturday were fixed. I also noticed that my probe switched from ctr-nue13 which it was always connected with to ctr-ams15 after 18 June and yesterday it got connected to ctr-ams14 but lost that connection again quite fast. My questions again: is that (probes getting disconnected all the time) something anyone else sees? Is there something on Atlas? side wrong or has my probe somehow lost the ability to stay connected for periods of more than a couple of minutes? There are again no obvious problems with my internet connection. TIA, Andre -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at gim.li Sun Jul 1 14:18:07 2018 From: ripe at gim.li (Benoit Lelievre) Date: Sun, 01 Jul 2018 14:18:07 +0200 Subject: [atlas] Probe seems DoA In-Reply-To: Message-ID: Alright, looks like I may have found a way to fix it. It appears that this probe's USB drive got corrupted. I pulled the drive, plugged it in my computer, deleted all of the partitions and re-created a single 8GB FAT32 partition then put it back on the probe. Once it booted with the re-formatted drive in the second light got to flashing instead of being stuck on. After a few minutes of that (I assume the probe rebuilt the drive for what it needs) the probe rebooted itself and it now seems to be behaving normally, the third and fourth lights are flashing the way my first probe was when I first connected it and it requested (and received) a DHCP address from my server. I guess I'll see in a few hours whether this takes. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From vnaumov at ripe.net Sun Jul 1 16:38:49 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Sun, 1 Jul 2018 16:38:49 +0200 Subject: [atlas] Probe connection not holding In-Reply-To: References: Message-ID: Hi Andre, During the back-end problems we got probes unevenly distributed across controllers. Lots of probes went to ams14 and started dumping results they collected being offline. The ams14 is the most powerful controller and it went online first. Therefore it was highly biased to attract disconnected probes. It caused major controller slowdown and we decided to speed up the redistribution process by manually disconnecting some probes away from ams14. Most likely your probe was one of the innocent victims. Sorry for the inconvenience wbr /vty On 7/1/18 2:21 AM, Andre Heinrichs wrote: > Hi everyone, > > Another day, another weird effect. My probe (29384) keeps losing its > connection to the Atlas systems. That seems to happen since the > backend problems from Saturday were fixed. I also noticed that my > probe switched from ctr-nue13 which it was always connected with to > ctr-ams15 after 18 June and yesterday it got connected to ctr-ams14 > but lost that connection again quite fast. > > My questions again: is that (probes getting disconnected all the time) > something anyone else sees? Is there something on Atlas? side wrong or > has my probe somehow lost the ability to stay connected for periods of > more than a couple of minutes? There are again no obvious problems > with my internet connection. > > TIA, > Andre From compyblog at gmail.com Sun Jul 1 16:41:33 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Sun, 1 Jul 2018 16:41:33 +0200 Subject: [atlas] Probe connection not holding In-Reply-To: References: Message-ID: Thank you for your information. I managed to get the probe back online in the meantime (I tried the USB resetting) and it seems to work fine. Again, thanks. On Sun 1. Jul 2018 at 16:38, Viktor Naumov wrote: > Hi Andre, > > During the back-end problems we got probes unevenly distributed across > controllers. Lots of probes went to ams14 and started dumping results > they collected being offline. The ams14 is the most powerful controller > and it went online first. Therefore it was highly biased to attract > disconnected probes. It caused major controller slowdown and we decided > to speed up the redistribution process by manually disconnecting some > probes away from ams14. Most likely your probe was one of the innocent > victims. > > Sorry for the inconvenience > > wbr > /vty > > On 7/1/18 2:21 AM, Andre Heinrichs wrote: > > Hi everyone, > > > > Another day, another weird effect. My probe (29384) keeps losing its > > connection to the Atlas systems. That seems to happen since the > > backend problems from Saturday were fixed. I also noticed that my > > probe switched from ctr-nue13 which it was always connected with to > > ctr-ams15 after 18 June and yesterday it got connected to ctr-ams14 > > but lost that connection again quite fast. > > > > My questions again: is that (probes getting disconnected all the time) > > something anyone else sees? Is there something on Atlas? side wrong or > > has my probe somehow lost the ability to stay connected for periods of > > more than a couple of minutes? There are again no obvious problems > > with my internet connection. > > > > TIA, > > Andre > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tapio.sokura at iki.fi Sun Jul 1 23:35:56 2018 From: tapio.sokura at iki.fi (Tapio Sokura) Date: Mon, 2 Jul 2018 00:35:56 +0300 Subject: [atlas] Probe seems DoA In-Reply-To: References: Message-ID: Hi, It is not unheard of to receive a probe with a bad usb stick. One of the probes I host stabilized once I replaced the usb drive that came with the probe with a working one. The probe was not stable during the few weeks after receiving it with the original usb stick. So if it fails again, you might want to try a different usb stick. Tapio On 1.7.2018 15:18, Benoit Lelievre wrote: > Alright, looks like I may have found a way to fix it. > > It appears that this probe's USB drive got corrupted. I pulled the drive, plugged it in my computer, deleted all of the partitions and re-created a single 8GB FAT32 partition then put it back on the probe. Once it booted with the re-formatted drive in the second light got to flashing instead of being stuck on. After a few minutes of that (I assume the probe rebuilt the drive for what it needs) the probe rebooted itself and it now seems to be behaving normally, the third and fourth lights are flashing the way my first probe was when I first connected it and it requested (and received) a DHCP address from my server. > > I guess I'll see in a few hours whether this takes. > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From mir at ripe.net Mon Jul 2 13:47:51 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 2 Jul 2018 13:47:51 +0200 Subject: [atlas] New on RIPE Labs: Outcome of the RIPE Atlas Anchor VMs Pilot Message-ID: <0f763d04-9138-8d46-83f9-49893c72839b@ripe.net> Dear colleagues, The pilot we ran to assess the feasibility of involving virtual machines in the pool of RIPE Atlas anchors is complete and the results are good. Please find more details on RIPE Labs: https://labs.ripe.net/Members/kistel/outcome-of-the-ripe-atlas-anchor-vms-pilot Kind regards, Mirjam K?hne RIPE NCC From ripe at gim.li Tue Jul 3 19:34:55 2018 From: ripe at gim.li (Benoit Lelievre) Date: Tue, 03 Jul 2018 19:34:55 +0200 Subject: [atlas] Probe seems DoA In-Reply-To: Message-ID: Thank you for the advice! So far so good. After re-partitioning the USB drive it started working and it's been solid ever since. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mir at ripe.net Wed Jul 4 15:24:46 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 4 Jul 2018 15:24:46 +0200 Subject: [atlas] New on RIPE Labs: Comparing Virtual and Metal RIPE Atlas Anchors Message-ID: <19783400-a324-f284-e317-d74704006289@ripe.net> Dear colleagues, We compared performance between virtual and physical RIPE Atlas anchors. Please find the results on RIPE Labs: https://labs.ripe.net/Members/stephen_strowes/comparing-virtual-and-metal-ripe-atlas-anchors Kind regards, Mirjam K?hne RIPE NCC From alarig at grifon.fr Tue Jul 10 00:34:23 2018 From: alarig at grifon.fr (Alarig Le Lay) Date: Tue, 10 Jul 2018 00:34:23 +0200 Subject: [atlas] Wrong TLSA for stat.ripe.net Message-ID: <20180709223422.wlg5x5zx6bje4gow@mew.swordarmor.fr> Hi, Since one week or so, I have a TLSA validation error for stat.ripe.net on TCP/443 at each time I visit https://atlas.ripe.net/ and I have the same result from the RIPE nlnog node: alarig at airmure ~ % echo '' | openssl s_client -connect atlas.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 8248E13AB5CA3BACAC63F15B831DA32F2CD54973EDF74E69B6A614B7295C02B4 alarig at airmure ~ % dig +short -t TLSA _443._tcp.atlas.ripe.net | awk '{ print $4 $5 }' 8248E13AB5CA3BACAC63F15B831DA32F2CD54973EDF74E69B6A614B7295C02B4 alarig at airmure ~ % echo '' | openssl s_client -connect stat.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 2A2B939449E847374121D4846E3117F23A0283C7B2818ED96C91D2808ABE4C0E alarig at airmure ~ % dig +short -t TLSA _443._tcp.stat.ripe.net | awk '{ print $4 $5 }' E3DC43427AA9F62D1E07BBE108AF62BEE84A454DB579FD57A4FFDFFD5A23E576 grifon at ripe01:~$ echo '' | openssl s_client -connect stat.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 2A2B939449E847374121D4846E3117F23A0283C7B2818ED96C91D2808ABE4C0E grifon at ripe01:~$ dig +short -t TLSA _443._tcp.stat.ripe.net | awk '{ print $4 $5 }' E3DC43427AA9F62D1E07BBE108AF62BEE84A454DB579FD57A4FFDFFD5A23E576 The commands are ugly but work on atlas.ripe.net. Could you please update it? Regards, -- Alarig Le Lay From wxcafe at wxcafe.net Thu Jul 12 17:12:45 2018 From: wxcafe at wxcafe.net (=?utf-8?B?Q2zDqW1lbnQgSGVydGxpbmcgKFd4Y2Fmw6kp?=) Date: Thu, 12 Jul 2018 15:12:45 +0000 Subject: [atlas] Transfer Anchor ownership Message-ID: <1b9cf0d48c5a13ac0ff0b8982b6525c5@mail.wxcafe.net> Hi, We have an anchor at the company I work for that has been associated with the wrong RIPE Atlas account. We're trying to move it from that (personal) atlas account to a shared netops account, but can't find a way to do this. Is there a way to do this ourselves, or can someone from RIPE Atlas do it for us? Cheers, -- Cl?ment 'wxcaf?' Hertling From rxa271 at case.edu Fri Jul 6 22:30:11 2018 From: rxa271 at case.edu (Rami Al-Dalky) Date: Fri, 6 Jul 2018 16:30:11 -0400 Subject: [atlas] DNS measurement using the Probe's resolvers Message-ID: Hi Everyone, I have a question about using the probe's list of resolvers when creating a DNS measurement. It is unclear to me whether the probe would send the query to all resolvers at the same time or not! Also, does the probe send the query to all resolvers in its list or to a subset of those resolvers? Is DNS eyeball implemented in the probes? Sincerely, Rami -------------- next part -------------- An HTML attachment was scrubbed... URL: From scg at gibbard.org Mon Jul 16 20:15:32 2018 From: scg at gibbard.org (Steve Gibbard) Date: Mon, 16 Jul 2018 11:15:32 -0700 Subject: [atlas] Global Traceroute Message-ID: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> I wrote front-end to traceroute from the RIPE Atlas probes. It looks like a standard looking glass ? you select a probe by location and AS number, enter a destination, and it does a traceroute. It?s on the web at https://www.globaltraceroute.com. If this looks useful, please check it out and tell me what you think. One of the things I've found frustrating when troubleshooting routing problems was the lack of information about inbound paths. Various measurement systems would tell me when performance was bad. Traceroutes from my own network would tell me what path traffic to a destination was taking outbound. Flow systems would tell me what interface inbound traffic was coming in on, and sometimes what peer it was coming through. But determining the full path inbound traffic was taking ? why users of some ISP in Asia were having their traffic show up at one of my POPs in Europe, for instance, was much more difficult. I?ve been using looking glasses and commercial performance monitoring systems that allow traceroutes from their probes, but those often weren?t where the end users were. RIPE Atlas did have probes where a lot of my end users were, so I started configuring one time measurements on RIPE Atlas whenever I needed a traceroute from a simulated end user. But finding a suitable probe and configuring the measurement was too cumbersome to do when I wasn?t pretty desperate. This is my attempt to solve that problem. Thanks, Steve From admin at support.od.ua Mon Jul 16 22:49:44 2018 From: admin at support.od.ua (Vladislav V. Prodan) Date: Mon, 16 Jul 2018 23:49:44 +0300 Subject: [atlas] Global Traceroute In-Reply-To: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> Message-ID: Hello. Thank you for your work. I will summarize my wishes: 1) After clicking the "Submit" button, the picture on the page should be shown, that the request is coming or the text "Loading ....", so that the user realizes that the request is not fast and did not hurry to leave the page. 2) If there is only one probes in the selected ASN, then after selecting ASN, this probe should also be selected. 3) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178 the top fields of sample #19178 are automatically filled. 4) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top fields of sample #19178 were automatically filled, in "Target Address" the value 1.1.1.1 was set and the request for construction trails. 5) It would be desirable that when https request https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly take a probe from the selected location (UK), automatically fill the top fields of this sample, the "Target Address" was exposed value 1.1.1.1 and automatically sent a request to build the route. 6) I want to work correctly in the console programs curl, lynx and wget. 7) Notes at the end of the route that "Target Address" is anycast address, especially for IP facebook, google, youtube and cloudflare. 8) reCAPTCHA is certainly good against abuse, but is more accountable limits on the number of requests. It is possible, after authorization through Google or facebook, to raise the limits of requests. 9) I want a correct recognition of ASN for gray IP - 10.137.128.1 (10.137.128.1) [AS ???] 10) I want a correct ASN recognition for some other IP - 185.1.50.68 (185.1.50.68) [AS ???] 12.581 ms -- Vladislav V. Prodan System & Network Administrator support.od.ua From graham at cloudpbx.ca Mon Jul 16 23:24:39 2018 From: graham at cloudpbx.ca (Graham Nelson-Zutter) Date: Mon, 16 Jul 2018 14:24:39 -0700 Subject: [atlas] Global Traceroute In-Reply-To: References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> Message-ID: Hi Steve & Vladislav, First off, thank you for sharing your hard work Steve. Global Traceroute is yet another tool showing the potential of the Atlas project. Are you using your own credits so that others may run these traceroutes? Thank you for your detailed review Vladislav. These are great suggestions. I support all of the recommendations you listed. Steve, is there interest in providing an open source version of this tool so that we may help make these modifications and enhancements? thank you, Graham Graham Nelson-Zutter CTO, Co-founder CloudPBX Inc. 204-1350 Burrard Street Vancouver, BC V6Z 0C2 +1 604 638 3848 ext 102 +1 604 674 7370 fax On Mon, Jul 16, 2018 at 1:49 PM, Vladislav V. Prodan wrote: > Hello. > > Thank you for your work. > > I will summarize my wishes: > > 1) After clicking the "Submit" button, the picture on the page should > be shown, that the request is coming or the text "Loading ....", so > that the user realizes that the request is not fast and did not hurry > to leave the page. > > 2) If there is only one probes in the selected ASN, then after > selecting ASN, this probe should also be selected. > > 3) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178 the top fields of sample > #19178 are automatically filled. > > 4) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top > fields of sample #19178 were automatically filled, in "Target Address" > the value 1.1.1.1 was set and the request for construction trails. > > 5) It would be desirable that when https request > https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly > take a probe from the selected location (UK), automatically fill the > top fields of this sample, the "Target Address" was exposed value > 1.1.1.1 and automatically sent a request to build the route. > > 6) I want to work correctly in the console programs curl, lynx and wget. > > 7) Notes at the end of the route that "Target Address" is anycast > address, especially for IP facebook, google, youtube and cloudflare. > > 8) reCAPTCHA is certainly good against abuse, but is more accountable > limits on the number of requests. It is possible, after authorization > through Google or facebook, to raise the limits of requests. > > 9) I want a correct recognition of ASN for gray IP - 10.137.128.1 > (10.137.128.1) [AS ???] > > 10) I want a correct ASN recognition for some other IP - 185.1.50.68 > (185.1.50.68) [AS ???] 12.581 ms > > > > -- > Vladislav V. Prodan > System & Network Administrator > support.od.ua > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Tue Jul 17 15:46:20 2018 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 17 Jul 2018 09:46:20 -0400 Subject: [atlas] Global Traceroute In-Reply-To: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> Message-ID: <972f5f9a-7ce3-c30c-010a-0c98da7a8266@ripe.net> Steve, Thank you very much for making this tool. It's very encouraging from our (ie. the Atlas team's) point of view to see people making useful tools based on the network. I encourage you to continue your work, perhaps even collaborate with others in an open source fashion to scale up, and also let us -- the Atlas team -- know if we can be of assistance. Regards, Robert On 2018-07-16 14:15, Steve Gibbard wrote: > I wrote front-end to traceroute from the RIPE Atlas probes. It looks like a standard looking glass ? you select a probe by location and AS number, enter a destination, and it does a traceroute. It?s on the web at https://www.globaltraceroute.com. If this looks useful, please check it out and tell me what you think. > > One of the things I've found frustrating when troubleshooting routing problems was the lack of information about inbound paths. Various measurement systems would tell me when performance was bad. Traceroutes from my own network would tell me what path traffic to a destination was taking outbound. Flow systems would tell me what interface inbound traffic was coming in on, and sometimes what peer it was coming through. But determining the full path inbound traffic was taking ? why users of some ISP in Asia were having their traffic show up at one of my POPs in Europe, for instance, was much more difficult. > > I?ve been using looking glasses and commercial performance monitoring systems that allow traceroutes from their probes, but those often weren?t where the end users were. RIPE Atlas did have probes where a lot of my end users were, so I started configuring one time measurements on RIPE Atlas whenever I needed a traceroute from a simulated end user. But finding a suitable probe and configuring the measurement was too cumbersome to do when I wasn?t pretty desperate. This is my attempt to solve that problem. > > Thanks, > Steve > From jterbeest at ripe.net Tue Jul 17 16:12:12 2018 From: jterbeest at ripe.net (Johan ter Beest) Date: Tue, 17 Jul 2018 16:12:12 +0200 Subject: [atlas] Transfer Anchor ownership In-Reply-To: <1b9cf0d48c5a13ac0ff0b8982b6525c5@mail.wxcafe.net> References: <1b9cf0d48c5a13ac0ff0b8982b6525c5@mail.wxcafe.net> Message-ID: <44040bcb-c7ee-abda-8c2d-0c9382da710d@ripe.net> Hi, As there was some confusion within RIPE itself whether this was handled, I am replying here now to let everybody know that this was indeed handled in a private conversation with the OP. Normally, requests for anchor ownership transfer should go to atlas at ripe.net and then our Customer Services department will handle them. Probe transfers on the other hand can be handled by the hosts themselves using the form on the probe page. In the future, we will reply to the list right away that we're replying in a private message. Hopefully, this will clear up the confusion ;) Kind regards, Johan ter Beest RIPE Atlas Team On 12/07/2018 17:12, Cl?ment Hertling (Wxcaf?) wrote: > Hi, > > We have an anchor at the company I work for that has been associated with the wrong RIPE Atlas > account. We're trying to move it from that (personal) atlas account to a shared netops account, but > can't find a way to do this. Is there a way to do this ourselves, or can someone from RIPE Atlas do > it for us? > > Cheers, > From scg at gibbard.org Tue Jul 17 18:40:45 2018 From: scg at gibbard.org (scg at gibbard.org) Date: Tue, 17 Jul 2018 09:40:45 -0700 Subject: [atlas] Global Traceroute In-Reply-To: References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> Message-ID: <7798EADE-ED92-49A5-988C-AAF1466F168E@gibbard.org> > On Jul 16, 2018, at 1:49 PM, Vladislav V. Prodan wrote: > > Hello. > > Thank you for your work. > Thanks for the feedback! > I will summarize my wishes: > > 1) After clicking the "Submit" button, the picture on the page should > be shown, that the request is coming or the text "Loading ....", so > that the user realizes that the request is not fast and did not hurry > to leave the page. Agreed. This is on my to do list. > > 2) If there is only one probes in the selected ASN, then after > selecting ASN, this probe should also be selected. This sounds like a good idea. I?ll work on it. > > 3) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178 the top fields of sample > #19178 are automatically filled. > > 4) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top > fields of sample #19178 were automatically filled, in "Target Address" > the value 1.1.1.1 was set and the request for construction trails. > > 5) It would be desirable that when https request > https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly > take a probe from the selected location (UK), automatically fill the > top fields of this sample, the "Target Address" was exposed value > 1.1.1.1 and automatically sent a request to build the route. > > 6) I want to work correctly in the console programs curl, lynx and wget. > I?m curious about the use case for this. Using the Atlas API, if you already know the probe ID, you do the trace route with two http transactions. The first one creates the measurement and returns a JSON containing a measurement ID. The second, 30 seconds to a minute later (thus the slowness of the web app to return results) sends the measurement ID and retrieves a JSON containing the results. What I?m adding is: - making it easier to find the right probes - turning two requests into one - supplying Atlas credits to pay for the traceroute - reformatting the JSON output into a traditional text-based traceroute output, which is easier for humans to read but maybe less useful if you?re generating the traceroutes from a machine. Are you looking for a faster way to do manual requests and get human readable output, trying to point an automated system at it, or some hybrid of the two? And if automated, is the human-readable output ideal, or would you be better off dealing with something a more machine readable format? > 7) Notes at the end of the route that "Target Address" is anycast > address, especially for IP facebook, google, youtube and cloudflare. I?m curious about the use case again. Also, is there a good source for that data, or would this be adding one at a time as I discover them? > > 8) reCAPTCHA is certainly good against abuse, but is more accountable > limits on the number of requests. It is possible, after authorization > through Google or facebook, to raise the limits of requests. This is largely an issue of resources. Thanks to a generous donor, I have enough credits for more than a million traceroutes. If I run through that due to human users, that will mean this is far more successful than I expect it to be, and there should be no problem either getting more donated, or coming up with a revenue model to buy them through Atlas sponsorship. But if I open it up for machine-generated measurements, it wouldn?t be that difficult for a single user to run through a million measurements. So, I?m certainly happy to accommodate measurement by machine or in mass quantities, but need to figure out how to make it sustainable. I have a few models in mind for that, but again it largely depends on the use cases. > > 9) I want a correct recognition of ASN for gray IP - 10.137.128.1 > (10.137.128.1) [AS ???] > > 10) I want a correct ASN recognition for some other IP - 185.1.50.68 > (185.1.50.68) [AS ???] 12.581 ms > The IP address to ASN mapping is coming from MaxMind?s GeoLite2 ASN database. Putting in an override for RFC1918 would be pretty easy. Other corrections should go through MaxMind ? it will fix a lot more than just this, and I don?t think it?s scalable for me to track every error in MaxMind. Thanks again for the feedback. It?s really useful. -Steve From bortzmeyer at nic.fr Tue Jul 17 19:07:42 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Jul 2018 13:07:42 -0400 Subject: [atlas] DNS measurement using the Probe's resolvers In-Reply-To: References: Message-ID: <20180717170742.GA12150@laperouse.bortzmeyer.org> On Fri, Jul 06, 2018 at 04:30:11PM -0400, Rami Al-Dalky wrote a message of 27 lines which said: > I have a question about using the probe's list of resolvers when > creating a DNS measurement. It is unclear to me whether the probe > would send the query to all resolvers at the same time or not! By default, to all resolvers. Look at measurement #15260120, for instance. Probe 25020 used three resolvers, 2001:730:3e42:1000::53, 192.168.178.1, and 2001:730:3e42::53, and you can see the results for all three. On the other hand, probe 17929 has just one resolver, 8.8.8.8, so you see only one object in the resultset array. With blaeu, you can display results for all the resolvers or only for the first one: % blaeu-resolve -r 10 --measurement-ID=15260120 atlas.ripe.net [2001:67c:2e8:22::c100:69e] : 10 occurrences Test #15260120 done at 2018-07-17T16:55:55Z % blaeu-resolve -r 10 --measurement-ID=15260120 --severalperprobe atlas.ripe.net [2001:67c:2e8:22::c100:69e] : 17 occurrences [NETWORK PROBLEM WITH RESOLVER] : 1 occurrences Test #15260120 done at 2018-07-17T16:55:55Z (More results in the second case, since some probes have more than one resolver.) > Is DNS eyeball implemented in the probes? I don't know. From bortzmeyer at nic.fr Tue Jul 17 19:11:59 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 17 Jul 2018 13:11:59 -0400 Subject: [atlas] Global Traceroute In-Reply-To: References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> Message-ID: <20180717171159.GB12150@laperouse.bortzmeyer.org> On Mon, Jul 16, 2018 at 11:49:44PM +0300, Vladislav V. Prodan wrote a message of 50 lines which said: > 6) I want to work correctly in the console programs curl, lynx and wget. Why? If you're a command-line fan like me, why not using the regular programs using the API? % blaeu-traceroute -r 1 -c BD --format 2001:67c:370:1998:9819:4f92:d0c0:e94d Measurement #15260300 Traceroute 2001:67c:370:1998:9819:4f92:d0c0:e94d from BD uses 1 probes 1 probes reported Test #15260300 done at 2018-07-17T17:10:40Z From: 2403:4000:1::f 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD Source address: 2403:4000:1::f Probe ID: 12148 1 2403:4000:1::1 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD [0.535, 0.572, 0.539] 2 2403:4000:0:2::1 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD [0.95, 1.024, 0.898] 3 2403:9300:80:7::1 58587 FIBERATHOME-BD Fiber at Home Limited, BD [1.353, 1.351, 1.35] 4 2403:9300:0:8::3d 58587 FIBERATHOME-BD Fiber at Home Limited, BD [1.71, 1.56, 1.931] 5 2001:5a0:2300:300::9 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [52.887, 52.6, 52.654] 6 2001:5a0:2300:300::15 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [179.184, 179.201, 183.813] 7 2001:5a0:2000:500::1 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [176.36, 176.342, 176.36] 8 2001:5a0:2000:500::2e 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [294.366, 292.972, 293.035] 9 2001:5a0:4500:100::9 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [294.013, 294.865, 293.539] 10 2001:5a0:12:100::19 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [287.969, 287.927, 288.095] 11 2001:5a0:12:100::72 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [288.075, 287.996, 287.941] 12 2001:5a0:3900::2 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [297.65, 297.437, 297.388] 13 2001:56b:a002:f::3 852 ASN852 - TELUS Communications Inc., CA [310.554, 309.815, 309.328] 14 2001:56b:8000:101::10 852 ASN852 - TELUS Communications Inc., CA [320.198, 320.096, 320.565] 15 2001:67c:370:1998:9819:4f92:d0c0:e94d 56554 IETF-MEETING IETF Meeting Network, CH [403.806, 404.518, 394.054] From admin at support.od.ua Tue Jul 17 19:58:15 2018 From: admin at support.od.ua (Vladislav V. Prodan) Date: Tue, 17 Jul 2018 20:58:15 +0300 Subject: [atlas] Global Traceroute In-Reply-To: <20180717171159.GB12150@laperouse.bortzmeyer.org> References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> <20180717171159.GB12150@laperouse.bortzmeyer.org> Message-ID: 2018-07-17 20:11 GMT+03:00 Stephane Bortzmeyer : > On Mon, Jul 16, 2018 at 11:49:44PM +0300, > Vladislav V. Prodan wrote > a message of 50 lines which said: > >> 6) I want to work correctly in the console programs curl, lynx and wget. > > Why? Firstly, your utility requires API-keys, which have problems getting them. Customers who own AS do not know how to get these keys or went too long to explain what and what they are for. Therefore, it is easier and faster for me, a freelancer, to use public shareware services. Secondly, the size of the package files. # pkg install net/py-ripe.atlas.tools Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 33 package(s) will be affected (of 0 checked): New packages to be INSTALLED: ... Number of packages to be installed: 33 The process will require 124 MiB more space. While the biggest utility is lynx has a size of 5.43MiB > If you're a command-line fan like me, why not using the regular > programs using the API? Utilities for simplicity and compactness will be available, comparable to mtr, then we will use them. In the meantime, mtr, winmtr, whois, telnet, dig and public LG are the basic tools for measurements. > > % blaeu-traceroute -r 1 -c BD --format 2001:67c:370:1998:9819:4f92:d0c0:e94d > Measurement #15260300 Traceroute 2001:67c:370:1998:9819:4f92:d0c0:e94d from BD uses 1 probes > 1 probes reported > Test #15260300 done at 2018-07-17T17:10:40Z > From: 2403:4000:1::f 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD > Source address: 2403:4000:1::f > Probe ID: 12148 -- Vladislav V. Prodan System & Network Administrator support.od.ua From philip.homburg at ripe.net Wed Jul 18 11:13:15 2018 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 18 Jul 2018 11:13:15 +0200 Subject: [atlas] DNS measurement using the Probe's resolvers In-Reply-To: References: Message-ID: On 2018/07/06 22:30 , Rami Al-Dalky wrote: > I have a question about using the probe's list of resolvers when > creating a DNS measurement.?It is unclear to me whether the probe would > send the query to all resolvers at the same time or not! Also, does the > probe send the query to all resolvers in its list or to a subset of > those resolvers? Is DNS eyeball implemented in the probes? Hi, The Atlas DNS measurement code sends one request at a time, in the order in which the DNS resolvers are listed in /etc/resolv.conf on the probe. In addition to measuring DNS, probe can also resolve a DNS name for the target of a measurement. In that case, the stub resolver that is built into libevent is used. That stub resolver does some clever and funky stuff. I don't know the details of how DNS queries are scheduled. Philip From yhjia03 at gmail.com Wed Jul 18 20:08:00 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Wed, 18 Jul 2018 13:08:00 -0500 Subject: [atlas] need help in RIPE atlas credits Message-ID: Dear all, I am Yihao, a Ph.D. student at Tsinghua University. Right now I plan to start an experiment with the RIPE atlas, but I don't have enough credits to fulfill the whole process. I am writing this letter to inquire if anyone can share some credits with me. (like 1 Million) Appreciate! (My RIPE atlas account: yhjia.03 at gmail.com) Many thanks, Yihao Tsinghua University -------------- next part -------------- An HTML attachment was scrubbed... URL: From yhjia03 at gmail.com Thu Jul 19 15:30:13 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Thu, 19 Jul 2018 08:30:13 -0500 Subject: [atlas] Need help in launching a periodical atlas measurement Message-ID: Dear all, I am in trouble with launching a periodical Ping measurement. [image: image.png] my script is like this, but my measurement always fails. I tried several times with different modification on "interval" and "spread". [image: image.png] one failed example can be reviewed here: https://atlas.ripe.net/measurements/15282285/ It works well when I launch a one-off measurement, but every time I try to launch a periodic measurement with the setting above, it fails all the time. it probably because the "is_oneoff", "interval", "spread" is set wrong, but I can't find a good example for it. The idea of this test measurement is to start a Ping test every 1 minute, from UTC-now to 5 minutes later. Thus, I'd like to have 5-set result in this measurement. Could you help me check where I set wrong? Many thanks, Yihao -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 78390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 153822 bytes Desc: not available URL: From thomas at bartelmess.io Thu Jul 19 15:44:24 2018 From: thomas at bartelmess.io (Thomas Bartelmess) Date: Thu, 19 Jul 2018 09:44:24 -0400 Subject: [atlas] need help in RIPE atlas credits In-Reply-To: References: Message-ID: Hi, I've transferred 1 M credits into your account. Thanks, - Thomas > On Jul 18, 2018, at 2:08 PM, Yihao Jia wrote: > > Dear all, > > I am Yihao, a Ph.D. student at Tsinghua University. > Right now I plan to start an experiment with the RIPE atlas, but I don't have enough credits to fulfill the whole process. > I am writing this letter to inquire if anyone can share some credits with me. (like 1 Million) > Appreciate! > > (My RIPE atlas account: yhjia.03 at gmail.com ) > > Many thanks, > Yihao > Tsinghua University > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.reutter at gmail.com Thu Jul 19 15:53:22 2018 From: michael.reutter at gmail.com (Michael Reutter) Date: Thu, 19 Jul 2018 15:53:22 +0200 Subject: [atlas] need help in RIPE atlas credits In-Reply-To: References: Message-ID: Hi Yiha, I transferred 4M to your account - hope this helps! all the best Michael Yihao Jia schrieb am Do., 19. Juli 2018 um 15:35 Uhr: > Dear all, > > I am Yihao, a Ph.D. student at Tsinghua University. > Right now I plan to start an experiment with the RIPE atlas, but I don't > have enough credits to fulfill the whole process. > I am writing this letter to inquire if anyone can share some credits with > me. (like 1 Million) > Appreciate! > > (My RIPE atlas account: yhjia.03 at gmail.com) > > Many thanks, > Yihao > Tsinghua University > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Thu Jul 19 16:03:07 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 19 Jul 2018 10:03:07 -0400 Subject: [atlas] Need help in launching a periodical atlas measurement In-Reply-To: References: Message-ID: <20180719140307.GA24208@laperouse.bortzmeyer.org> On Thu, Jul 19, 2018 at 08:30:13AM -0500, Yihao Jia wrote a message of 4181 lines which said: > I am in trouble with launching a periodical Ping measurement. > [image: image.png] It is strange to send screenshots instead of text... > my script is like this, but my measurement always fails. What's the return code and the JSON result? Atlas returns pretty good diagnostics. Anyway, to get help here, it would probably help to tell us the actual JSON data sent (and not as a screenshot). From robert at vojcik.net Thu Jul 19 16:42:49 2018 From: robert at vojcik.net (Robert Vojcik) Date: Thu, 19 Jul 2018 16:42:49 +0200 Subject: [atlas] Need help in launching a periodical atlas measurement In-Reply-To: References: Message-ID: <88c42ab7-b6fb-bcd8-eb3c-d7a4d422addf@vojcik.net> Hi, it looks like the probe you are targeting maybe has some problems. Try instead of using this exacpt probe determine that you want measurement from 1 probe from some area or country and let Atlas to pick one or simply try different probe. If you are sure probe is OK, maybe like you mentioned you did something wrong. Try use web interface to create measurement and you will see if it's still fails. P.S. On the bottom of create measurement site is "Measurement API Compatible Specification" where you can see JSON interpretation of that measurement. R?bert Voj??k email: robert at vojcik.net From yhjia03 at gmail.com Thu Jul 19 17:54:52 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Thu, 19 Jul 2018 10:54:52 -0500 Subject: [atlas] For help: launching a periodical atlas measurement In-Reply-To: References: Message-ID: Dear all, I am so sorry for using a screenshot for my last email. And I'd like to redescribe the problem I have. I'd like to launch a periodic Ping measurement (with python). It starts at UTC-now to (for example) 5 minutes later. I'd like the probe do the Ping test in every 1 minute. Thus I can have 5 results in this measurement. I am a little confused because all example on documents is one-off. I guess error might happen around "is_oneoff", "interval", "spread". source code for this test is below and in the attachment. Could you help me in checking where I get wrong? Many thanks, Yihao ---------------------------------------------------------------------------------------------- from datetime import datetime, timedelta from ripe.atlas.cousteau import ( Ping, AtlasSource, AtlasCreateRequest ) ATLAS_API_KEY = "" source2 = AtlasSource( requested=1, type="probes", value="35704" ) ping = Ping( af=4, target="202.112.51.179", description="Test for periodic Ping test", packets=1, ) def request(): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow(), stop_time=(datetime.utcnow() + timedelta(minutes=5)), key=ATLAS_API_KEY, measurements=[ping], sources=[source2], is_oneoff=False, interval=60, spread=60 ) (is_success, response) = atlas_request.create() return is_success, response if __name__ == '__main__': is_success, response = request() -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: periodic_ping.py Type: text/x-python Size: 1069 bytes Desc: not available URL: From me at fu.is Thu Jul 19 15:40:40 2018 From: me at fu.is (me at fu.is) Date: Thu, 19 Jul 2018 14:40:40 +0100 Subject: [atlas] need help in RIPE atlas credits In-Reply-To: References: Message-ID: Hello, Providing that this breaks no rules. Enjoy your 1 million Regards, Thomas On 2018-07-18 19:08, Yihao Jia wrote: > Dear all, > > I am Yihao, a Ph.D. student at Tsinghua University. > Right now I plan to start an experiment with the RIPE atlas, but I > don't have enough credits to fulfill the whole process. > I am writing this letter to inquire if anyone can share some credits > with me. (like 1 Million) > Appreciate! > > (My RIPE atlas account: yhjia.03 at gmail.com) > > Many thanks, > Yihao > Tsinghua University From yhjia03 at gmail.com Thu Jul 19 17:15:41 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Thu, 19 Jul 2018 10:15:41 -0500 Subject: [atlas] need help in RIPE atlas credits In-Reply-To: References: Message-ID: Dear Thomas, Thank you so much for your kind help! It will definitely help me a lot! I really appreciate it! Many thanks! Yihao On Thu, 19 Jul 2018 at 08:40, wrote: > Hello, > > Providing that this breaks no rules. Enjoy your 1 million > > Regards, > Thomas > > On 2018-07-18 19:08, Yihao Jia wrote: > > Dear all, > > > > I am Yihao, a Ph.D. student at Tsinghua University. > > Right now I plan to start an experiment with the RIPE atlas, but I > > don't have enough credits to fulfill the whole process. > > I am writing this letter to inquire if anyone can share some credits > > with me. (like 1 Million) > > Appreciate! > > > > (My RIPE atlas account: yhjia.03 at gmail.com) > > > > Many thanks, > > Yihao > > Tsinghua University > -- Sincerely. Yihao Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From yhjia03 at gmail.com Thu Jul 19 17:16:24 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Thu, 19 Jul 2018 10:16:24 -0500 Subject: [atlas] need help in RIPE atlas credits In-Reply-To: References: Message-ID: Dear Thomas, I got your 1M credits! Thank you so much for your kind help! It will definitely help me a lot! I really appreciate it! Many thanks! Yihao On Thu, 19 Jul 2018 at 08:44, Thomas Bartelmess wrote: > Hi, > > I've transferred 1 M credits into your account. > > Thanks, > > - Thomas > > On Jul 18, 2018, at 2:08 PM, Yihao Jia wrote: > > Dear all, > > I am Yihao, a Ph.D. student at Tsinghua University. > Right now I plan to start an experiment with the RIPE atlas, but I don't > have enough credits to fulfill the whole process. > I am writing this letter to inquire if anyone can share some credits with > me. (like 1 Million) > Appreciate! > > (My RIPE atlas account: yhjia.03 at gmail.com) > > Many thanks, > Yihao > Tsinghua University > > > -- Sincerely. Yihao Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Thu Jul 19 20:30:29 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 19 Jul 2018 14:30:29 -0400 Subject: [atlas] Global Traceroute In-Reply-To: References: <8DB727BB-65B7-467F-AE36-917CF335ACB3@gibbard.org> <20180717171159.GB12150@laperouse.bortzmeyer.org> Message-ID: <20180719183029.GA30200@laperouse.bortzmeyer.org> On Tue, Jul 17, 2018 at 08:58:15PM +0300, Vladislav V. Prodan wrote a message of 57 lines which said: > Firstly, your utility requires API-keys, which have problems getting > them. Fair enough. On the other hand, this means that the Web site needs credits and anonymous Web clients can eat them at will, so it may not be sustainable. > # pkg install net/py-ripe.atlas.tools ... > The process will require 124 MiB more space. > > While the biggest utility is lynx has a size of 5.43MiB Well, Blaeu may be smaller but, anyway, is 124 MiB really important (and many packages are shared with other stuff), these days? From fungyuensang_mf at hotmail.com Thu Jul 19 20:23:58 2018 From: fungyuensang_mf at hotmail.com (Matthew Fung) Date: Thu, 19 Jul 2018 18:23:58 +0000 Subject: [atlas] Inquiry: RIPE Atlas credits M Fung Message-ID: Hello, My name is Matthew, I am an undergrad studying CS at University of British Columbia. I've recently discovered the work done by RIPE and I'm really interested in using Atlas for a research project. I am wondering if anyone is willing to share credits in order to make this possible. I aim to use no more than 1M credits. (My user info is included below) Thanks, Matthew Fung RIPE ID: y6c0b at ugrad.cs.ubc.ca From james at cyberinvasion.net Thu Jul 19 20:39:18 2018 From: james at cyberinvasion.net (James Gannon) Date: Thu, 19 Jul 2018 18:39:18 +0000 Subject: [atlas] Inquiry: RIPE Atlas credits M Fung In-Reply-To: References: Message-ID: <1D084BD1-9BC7-409F-B8DD-249774874CDA@cyberinvasion.net> Sending you 1M credits now. > On 19 Jul 2018, at 20:23, Matthew Fung wrote: > > Hello, > > My name is Matthew, I am an undergrad studying CS at University of > British Columbia. > > I've recently discovered the work done by RIPE and I'm really interested > in using Atlas for a research project. > > I am wondering if anyone is willing to share credits in order to make > this possible. > > I aim to use no more than 1M credits. (My user info is included below) > > > Thanks, > > Matthew Fung > > RIPE ID: y6c0b at ugrad.cs.ubc.ca > From bortzmeyer at nic.fr Thu Jul 19 20:58:33 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 19 Jul 2018 14:58:33 -0400 Subject: [atlas] Need help: launching a periodical atlas measurement In-Reply-To: References: Message-ID: <20180719185833.GB30200@laperouse.bortzmeyer.org> On Thu, Jul 19, 2018 at 10:47:54AM -0500, Yihao Jia wrote a message of 192 lines which said: > I am a little confused because all example on documents is one-off. I guess > error might happen around "is_oneoff", "interval", "spread". > source code for this test is below and in the attachment. "is_oneoff" is off by default. "interval" is documented as "In normal (not one-off) measurements, this value represents the number of seconds between measurements by a single probe." I never tried "spread". I don't know the exact JSON you sent but this one worked (5 minutes, 1 minute between each test): {'definitions': [{'target': 'fr-ilm-as57119.anchors.atlas.ripe.net', 'af': 4, 'interval': 60, 'packets': 1, 'type': 'ping', 'description': 'Ping fr-ilm-as57119.anchors.atlas.ripe.net'}], 'start_time': 1532026200, 'stop_time': 1532026500, 'probes': [{'requested': 1, 'type': 'area', 'value': 'WW'}]} And it gave this measurement: https://atlas.ripe.net/measurements/15297080/ From yhjia03 at gmail.com Fri Jul 20 07:50:39 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Fri, 20 Jul 2018 00:50:39 -0500 Subject: [atlas] Is there a max running measurement number for a user Message-ID: Dear all, Is there a max running measurement number for a user? I try to launch about 800 measurements, but only about 150 of them succeed and keep running, while another 650 fail with the description "overlimited denied" one of the fail measurement is: https://atlas.ripe.net/measurements/15302198/ Do you know what's the reason I failed? (btw, I am wondering how to check the reason why a measurement is failed by the measurement id?) Many thanks, Yihao -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Fri Jul 20 14:59:30 2018 From: camin at ripe.net (Chris Amin) Date: Fri, 20 Jul 2018 14:59:30 +0200 Subject: [atlas] Is there a max running measurement number for a user In-Reply-To: References: Message-ID: <59020e59-f22e-6135-e873-79652878df77@ripe.net> Hi Yihao, On 20/07/2018 07:50, Yihao Jia wrote: > Is there a max running measurement number for a user? > > I try to launch about 800 measurements, but only about 150 of them > succeed?and keep running, while another 650 fail with the?description > "overlimited?denied" > one of the fail measurement > is:?https://atlas.ripe.net/measurements/15302198/ There are indeed limits on the number of concurrent measurements, amongst other kinds of limits. They are documented here: https://atlas.ripe.net/docs/udm/#rate-limits It is possible for limits to be temporarily increased to allow people to perform research. If you'd like to email me directly with the outline of your proposed experiment then I should be able to either increase your limits temporarily and/or advise you on using RIPE Atlas more efficiently. > Do you know what's the reason I failed? > (btw, I am wondering how to check the?reason why a measurement is failed > by the measurement id?) You can see the status of the measurement using the API: https://atlas.ripe.net/api/v2/measurements/15302198/ In this case the status is "Scheduling denied", which is the delayed version of the "overlimited denied" message that you saw with the other measurements. This is because we do an initial check when you POST and a second check when we are about to allocate probes. The other measurement that you mentioned: https://atlas.ripe.net/api/v2/measurements/15282285/ has a status of "Failed". In this case it is probably because the stop time is too close to the time that you scheduled the measurement so it didn't have a chance to run. Try increasing the stop time to a point further in the future. The statuses of measurements are not currently displayed clearly on the web site, but that will be changing in the near future as we are overhauling the measurement details pages. Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From yhjia03 at gmail.com Sat Jul 21 07:31:26 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Sat, 21 Jul 2018 00:31:26 -0500 Subject: [atlas] Looking for advise and temporarily limits increment for research Message-ID: To whom it may help, My name is Yihao. I am a Ph.D. student. Recently I am doing a research with RIPE Atlas. However, my research requires many measurements in a short period, which breaks several rules of the Rate Limits. Since I really like and in hurry to use Atlas to support my research, is there any advice I can get from this? I'd like to describe why it would be necessary for my research. And if possible, may I get a temporarily limit increment for 10 days? Many thanks, Yihao Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at eckel-edv.de Sat Jul 21 14:06:22 2018 From: lists at eckel-edv.de (Peter Eckel) Date: Sat, 21 Jul 2018 14:06:22 +0200 Subject: [atlas] Looking for advise and temporarily limits increment for research In-Reply-To: References: Message-ID: Hi Jia, did you read the mail vom Chris Amin from yesterday? I guess that should answer everything. I'd get in touch with Chris and discuss the rest directly. Cheers, Peter. From yhjia03 at gmail.com Sat Jul 21 16:32:12 2018 From: yhjia03 at gmail.com (Yihao Jia) Date: Sat, 21 Jul 2018 09:32:12 -0500 Subject: [atlas] Looking for advise and temporarily limits increment for research In-Reply-To: References: Message-ID: Hey Peter, Thanks for the help! I did send an email to Chris Amin (camin at ripe.net), but there might be some problem with my Gmail system and I cannot get his reply, or just because he is busy these hours. I am sorry that I am in a hurry for this issue, and my research system involves several parts and they work simultaneously, while the limit regulation of RIPE atlas part fails the process of my whole system every day. And I really need to deal with this. Since I haven't connected to Chris yet, could you help me ping him and loop me back in any possible way? Thanks, Yihao (below is the email I sent to Chris yesterday.) ------------------------------------------------------------------------------------------------------------------------------------ Dear Chris, Thank for helping me! I am a Ph.D. student. The reason why I try to launch so many measurements is just for research. And I wish the rate limits could be temporarily ? ? increased for 10 days, since I probably might exceed most of these rules. Generally, my research is like this. --- Part 1. I have 860 targets to ping, and thus 730 measurements. And for each target, I would like to use a fixed set of 100 probes in the measurement. For each of the measurement, I'd like the target to be Pinged by these 100 probes on every 1 hour, and the measurement is planned to stop 12 hours later after the measurement start. Thus, if one probe sent 3 packets at each ping, the total credits will be 3,096,000 (730*12*100*3=3,096,000). Part 2. This looks like a random measurement. My research is about an Internet anomalies detection system. So every time my system triggers an alarm, (the alarm would set for 1 of the 730 targets), I'd like to start an instant, and probably one-off measurement from the previous 100 probes to the alarmed target. The question is this anomalies detection system is still under improvement, so I don't exactly know how many measurements might concurrently be started at the same time. --- (The 730 targets are elaborately selected and necessary to me because I need the dataset as many as possible to examine the accuracy of the system) I check the rules at: https://atlas.ripe.net/docs/udm/#rate-limits It makes me feel like I might exceed many rules intentionally or unintentional. Considering I am in a huge hurry to examine this system, I'd very like the limits for these rules be temporarily increased. I appreciate every suggestion and help on this! My RIPE atlas account is: yhjia.03 at gmail.com Many thanks, Yihao On Sat, 21 Jul 2018 at 07:06, Peter Eckel wrote: > Hi Jia, > > did you read the mail vom Chris Amin from yesterday? I guess that should > answer everything. I'd get in touch with Chris and discuss the rest > directly. > > Cheers, > > Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From belafkih.hayat at gmail.com Sat Jul 21 19:09:21 2018 From: belafkih.hayat at gmail.com (BELLAFKIH hayat) Date: Sat, 21 Jul 2018 19:09:21 +0200 Subject: [atlas] Processing RIPE Atlas data as Big Data Message-ID: Dear RIPE Atlas users, I am studying the processing of the data collected by the probes as a Big Data problem. For instance, one hour of traceroute data count for 500 Mo (bzip2), so 7 Go of data in text format. Can you share with me how you deal with these data in practice. are you using a super machine, Big Data tools? ?best regards, Hayat? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.oghia at gmail.com Sun Jul 22 16:36:02 2018 From: mike.oghia at gmail.com (Michael J. Oghia) Date: Sun, 22 Jul 2018 16:36:02 +0200 Subject: [atlas] Looking for advise and temporarily limits increment for research In-Reply-To: References: Message-ID: Hi Yihao, I'd just wait a couple more days since the email was sent on a Friday, and he might not have seen it yet. Best, -Michael On Sat, Jul 21, 2018 at 4:32 PM, Yihao Jia wrote: > Hey Peter, > > Thanks for the help! > > I did send an email to Chris Amin (camin at ripe.net), but there might be > some problem with my Gmail system and I cannot get his reply, or just > because he is busy these hours. > > I am sorry that I am in a hurry for this issue, and my research system > involves several parts and they work simultaneously, while the limit > regulation of RIPE atlas part fails the process of my whole system every > day. And I really need to deal with this. > > Since I haven't connected to Chris yet, could you help me ping him and > loop me back in any possible way? > > Thanks, > Yihao > > (below is the email I sent to Chris yesterday.) > ------------------------------------------------------------ > ------------------------------------------------------------------------ > > > Dear Chris, > > Thank for helping me! > > I am a Ph.D. student. The reason why I try to launch so many measurements > is just for research. > And I wish the rate limits could be > temporarily > ? ? > increased for 10 days, since I probably might > exceed > most of these rules. > > > Generally, my research is like this. > --- > Part 1. > I have 860 targets to ping, and thus 730 measurements. And for each > target, I would like to use a fixed set of 100 probes in the measurement. > For each of the measurement, I'd like the target to be Pinged by these 100 > probes on every 1 hour, and the measurement is planned to stop 12 hours > later after the measurement start. Thus, if one probe sent 3 packets at > each ping, the total credits will be 3,096,000 (730*12*100*3=3,096,000). > > Part 2. > This looks like a random measurement. My research is about an Internet > anomalies detection system. So every time my system triggers an alarm, (the > alarm would set for 1 of the 730 targets), I'd like to start an instant, > and probably one-off measurement from the previous 100 probes to the > alarmed target. The question is this anomalies detection system is still > under improvement, so I don't exactly know how many measurements might > concurrently be started at the same time. > --- > (The 730 targets are elaborately selected and necessary to me because I > need the dataset as many as possible to examine the accuracy of the system > ) > > > I check the rules at: https://atlas.ripe.net/docs/udm/#rate-limits > It makes me feel like I might exceed many rules intentionally > or unintentional. > Considering I am in a huge hurry to examine this system, I'd very like the > limits for these rules be temporarily increased. > > I appreciate every suggestion and help on this! > My RIPE atlas account is: yhjia.03 at gmail.com > > Many thanks, > Yihao > > > > > On Sat, 21 Jul 2018 at 07:06, Peter Eckel wrote: > >> Hi Jia, >> >> did you read the mail vom Chris Amin from yesterday? I guess that should >> answer everything. I'd get in touch with Chris and discuss the rest >> directly. >> >> Cheers, >> >> Peter. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at ripe.net Tue Jul 24 12:05:33 2018 From: sds at ripe.net (Stephen D. Strowes) Date: Tue, 24 Jul 2018 12:05:33 +0200 Subject: [atlas] Processing RIPE Atlas data as Big Data In-Reply-To: References: Message-ID: Hi, I assume you're referring to the daily dumps that we release here: https://data-store.ripe.net/datasets/atlas-daily-dumps/ There are a couple of things that I find are relatively slow to deal with on the command line: standard bzip2 tooling, and jq for json parsing. So I lean on a couple of other tools to speed things up for me: - the lbzip2 suite parallelises parts of the compress/decompress pipeline - GNU parallel can split data in a pipe onto one process per core So, for example, on my laptop I can reasonably quickly pull out all of the traceroutes my own probe ran: lbzcat traceroute-2018-07-23T0700.bz2 | parallel -q --pipe jq '. | select(.prb_id == 14277)' St?phane has written about using jq to parse Atlas results on labs.ripe.net also: https://labs.ripe.net/Members/stephane_bortzmeyer/processing-ripe-atlas-results-with-jq Happy to hear from others what tools they use for data processing! Cheers, S. On 21/07/2018 19:09, BELLAFKIH hayat wrote: > Dear RIPE Atlas users, > > I am studying the processing of the data collected by the probes as a > Big Data problem. For instance, one hour of traceroute data count for > 500 Mo (bzip2), so 7 Go of data in text format. Can you share with me > how you deal with these data in practice. > are you using a super machine, Big Data tools? > > ?best regards, > Hayat? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From belafkih.hayat at gmail.com Thu Jul 26 11:51:06 2018 From: belafkih.hayat at gmail.com (BELLAFKIH hayat) Date: Thu, 26 Jul 2018 11:51:06 +0200 Subject: [atlas] The three generations of the Atlas probes : technical details Message-ID: Hi, I hope validate some details about the Atlas probes. I try to get these details by consulting the resources: 1. https://atlas.ripe.net/docs/probe-v1/ 2. https://atlas.ripe.net/docs/probe-v2/ 3. https://atlas.ripe.net/docs/probe-v3/ But no technical details given. By reading some presentations, I create the table bellow. Now, I hope if you can validate these details and complete the information about the CPU. It will be good if you can add the technical details for each generation of the probes. Thanks in advance. *Hayat BELLAFKIH* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pictures.png Type: image/png Size: 117295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: details.png Type: image/png Size: 63440 bytes Desc: not available URL: From cs at fnx.li Fri Jul 27 14:34:50 2018 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Fri, 27 Jul 2018 14:34:50 +0200 Subject: [atlas] The three generations of the Atlas probes : technical details In-Reply-To: References: Message-ID: <89ef5921-096b-4670-982d-621f49cdfc5d@fnx.li> Afaik there's an Atheros AR9331 in TL-MR3020 devices. It's a 32bit CPU. -- Regards, Christian