From gponikie at akamai.com Thu Dec 5 18:39:27 2019 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Thu, 5 Dec 2019 17:39:27 +0000 Subject: [atlas] Probes connected to 4G/LTE Message-ID: <197F7076-3C7B-462F-8EEA-B82914A0886F@akamai.com> Hi all! I'm thinking about becoming ambassador to deploy more probes in Poland including rural areas where sometimes the only option to get access to the Internet is 4G/LTE. I'm interested what is your experience with 4G/LTE and Atlas probes. What tags you use to mark them? How stable they are? What RTT you see to first and second hop? Regards, Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From gboonie at gmail.com Thu Dec 5 19:15:46 2019 From: gboonie at gmail.com (dave) Date: Thu, 5 Dec 2019 19:15:46 +0100 Subject: [atlas] Probes connected to 4G/LTE In-Reply-To: <197F7076-3C7B-462F-8EEA-B82914A0886F@akamai.com> References: <197F7076-3C7B-462F-8EEA-B82914A0886F@akamai.com> Message-ID: Hi, My probe on 4g on Vodafone Netherlands can be found here. https://atlas.ripe.net/probes/13308/ Go ahead and run some test. If you have any further questions, let me know. Dave > Op 5 dec. 2019 om 18:40 heeft Ponikierski, Grzegorz het volgende geschreven: > > ? > Hi all! > > I'm thinking about becoming ambassador to deploy more probes in Poland including rural areas where sometimes the only option to get access to the Internet is 4G/LTE. I'm interested what is your experience with 4G/LTE and Atlas probes. What tags you use to mark them? How stable they are? What RTT you see to first and second hop? > > Regards, > Grzegorz -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at brite.cz Fri Dec 6 09:24:19 2019 From: ripe at brite.cz (ripe at brite.cz) Date: Fri, 06 Dec 2019 09:24:19 +0100 Subject: [atlas] =?utf-8?q?Probes_connected_to_4G/LTE?= In-Reply-To: <197F7076-3C7B-462F-8EEA-B82914A0886F@akamai.com> References: <197F7076-3C7B-462F-8EEA-B82914A0886F@akamai.com> Message-ID: <20191206092419.972E63B0@centrum.cz> Hi, You may want to start from http://sg-pub.ripe.net/petros/population_coverage/country.html?name=PL to see whether there is coverage of your networks already. I think Atlas is more interested in covering "networks" (AS) than geographical locations. Furthermore you can run measurement on probes tagged LTE/4G, such as https://atlas.ripe.net/measurements/23527048/ - I see one probe from Poland there. Although the user tags are not completely reliable, it may still give you good overall image. Cheers Jiri ______________________________________________________________ > Od: "Ponikierski, Grzegorz" > Komu: "ripe-atlas at ripe.net" > Datum: 05.12.2019 18:50 > P?edm?t: [atlas] Probes connected to 4G/LTE > >Hi all! > >I'm thinking about becoming ambassador to deploy more probes in Poland including rural areas where sometimes the only option to get access to the Internet is 4G/LTE. I'm interested what is your experience with 4G/LTE and Atlas probes. What tags you use to mark them? How stable they are? What RTT you see to first and second hop? > >Regards, >Grzegorz > > From rami.dalky at gmail.com Tue Dec 10 21:52:11 2019 From: rami.dalky at gmail.com (Rami Al-Dalky) Date: Tue, 10 Dec 2019 12:52:11 -0800 Subject: [atlas] Anchor VM security Message-ID: Hi, If someone is planning to host a VM anchor, what are the security measures that RIPE Atlas can provide? For example, protecting the VM from being compromised by an attacker. Any information about this is highly appreciated because the plan is host several anchors. Thanks, Rami -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Dec 12 13:27:05 2019 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 12 Dec 2019 13:27:05 +0100 Subject: [atlas] Anchor VM security In-Reply-To: References: Message-ID: On 2019-12-10 21:52, Rami Al-Dalky wrote: > Hi, > > If someone is planning to host a VM anchor, what are the security > measures that RIPE Atlas can?provide? For?example, protecting the VM > from being compromised by an attacker. > > Any information about this is highly appreciated because the plan is > host several anchors. > > Thanks, > Rami Hello, There's no single best answer to this question. The operations team behind anchors are keeping the machinery updated with all the latest patches, just like you'd do with any Internet-connected server. We consider it very important when we manage these machines. They also provide very limited services (e.g. DNS and HTTP(S)). On the other hand the very reason for installing an anchor is to make it reachable (be measured) and to reach other hosts (to measure) so forms of firewalling are counterproductive to the purpose. When in doubt, we recommend placing these "just outside your firewall". Regards, Robert From anandb at ripe.net Fri Dec 13 11:18:15 2019 From: anandb at ripe.net (Anand Buddhdev) Date: Fri, 13 Dec 2019 11:18:15 +0100 Subject: [atlas] Letsencrypt certificates on anchors Message-ID: <771a4d6f-5be8-d2de-6be1-5438f4bb0b6b@ripe.net> Dear colleagues, Some time ago, there was discussion on this list about deploying Letsencrypt certificates on anchors. We had said we would investigate the possibility of doing this. We are pleased to report that we have worked out how to do this seamlessly. Early next week, all RIPE Atlas anchors will switch to Letsencrypt certificates. Note that we will re-use the existing keys on the anchors to request the Letsencrypt certificates. The TLSA records of all anchors are pinned to these private keys, and so they will not change. Regards, Anand Buddhdev RIPE NCC From mike.oghia at gmail.com Fri Dec 13 11:24:32 2019 From: mike.oghia at gmail.com (Michael J. Oghia) Date: Fri, 13 Dec 2019 11:24:32 +0100 Subject: [atlas] Letsencrypt certificates on anchors In-Reply-To: <771a4d6f-5be8-d2de-6be1-5438f4bb0b6b@ripe.net> References: <771a4d6f-5be8-d2de-6be1-5438f4bb0b6b@ripe.net> Message-ID: Dear Anand, As a big supporter of both Let's Encrypt and RIPE Atlas, this is great news! I'm happy to hear this, and appreciate the RIPE NCC's commitment to it. Best, -Michael On Fri, Dec 13, 2019 at 11:18 AM Anand Buddhdev wrote: > Dear colleagues, > > Some time ago, there was discussion on this list about deploying > Letsencrypt certificates on anchors. We had said we would investigate > the possibility of doing this. > > We are pleased to report that we have worked out how to do this > seamlessly. Early next week, all RIPE Atlas anchors will switch to > Letsencrypt certificates. Note that we will re-use the existing keys on > the anchors to request the Letsencrypt certificates. The TLSA records of > all anchors are pinned to these private keys, and so they will not change. > > Regards, > Anand Buddhdev > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Fri Dec 13 11:28:41 2019 From: carsten at schiefner.de (Carsten Schiefner) Date: Fri, 13 Dec 2019 11:28:41 +0100 Subject: [atlas] Letsencrypt certificates on anchors In-Reply-To: <771a4d6f-5be8-d2de-6be1-5438f4bb0b6b@ripe.net> References: <771a4d6f-5be8-d2de-6be1-5438f4bb0b6b@ripe.net> Message-ID: <6e5ef079-f5b5-4b18-9d3f-db13f66dba51.maildroid@localhost> Excellent news, Anand - thanks a lot! Von meinem Android-Ger?t gesendet. -----Original Message----- From: Anand Buddhdev To: RIPE Atlas Sent: Fr., 13 Dez. 2019 11:19 Subject: [atlas] Letsencrypt certificates on anchors Dear colleagues, Some time ago, there was discussion on this list about deploying Letsencrypt certificates on anchors. We had said we would investigate the possibility of doing this. We are pleased to report that we have worked out how to do this seamlessly. Early next week, all RIPE Atlas anchors will switch to Letsencrypt certificates. Note that we will re-use the existing keys on the anchors to request the Letsencrypt certificates. The TLSA records of all anchors are pinned to these private keys, and so they will not change. Regards, Anand Buddhdev RIPE NCC From gboonie at gmail.com Fri Dec 13 21:55:26 2019 From: gboonie at gmail.com (Dave .) Date: Fri, 13 Dec 2019 21:55:26 +0100 Subject: [atlas] measurement page broken? Message-ID: Hi, I just started 2 measurements like 10 minutes ago but it does seem something broke. https://atlas.ripe.net/measurements/23631307/#!probes Same issue here: https://atlas.ripe.net/measurements/23631303/#!probes I get to see a spinner instead of the results. Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdenhertog at ripe.net Sat Dec 14 14:33:58 2019 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Sat, 14 Dec 2019 14:33:58 +0100 Subject: [atlas] measurement page broken? In-Reply-To: References: Message-ID: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> hi Dave, I can confirm that there?s a problem with the measurements with ids your mentioning. The creation process never finished for these measurements. The measurements with the ids 23631303,23631304,23631305 and 23631307 all never were created. For what I can see now this seems to be a transient problem. If you see other measurements with the same problem please report them to us. We will look into the cause of this problem monday, greetings, Jasper den Hertog RIPE Atlas team > On 13 Dec 2019, at 21:55, Dave . wrote: > > Hi, > > I just started 2 measurements like 10 minutes ago but it does seem something broke. > > https://atlas.ripe.net/measurements/23631307/#!probes > > Same issue here: > https://atlas.ripe.net/measurements23631307#!probes > > I get to see a spinner instead of the results. > > Thanks, > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2639 bytes Desc: not available URL: From gboonie at gmail.com Sun Dec 15 18:28:56 2019 From: gboonie at gmail.com (Dave .) Date: Sun, 15 Dec 2019 18:28:56 +0100 Subject: [atlas] measurement page broken? In-Reply-To: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> References: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> Message-ID: Hi Jasper, Same result for new tests unfortunately. https://atlas.ripe.net/measurements/23650744/#!general https://atlas.ripe.net/measurements/23650745/ In case you want to try and reproduce it, I am trying to start a one-off DNS test for spotify.com or grc.com and use 74.82.42.42 (Hurricane Electric) as a resolver. The resolver in Amsterdam has an issue currently and I'd like to find out whether other nodes in other locations have the same issue or not. The issue was reported to HE so I guess they will have fixed it soon. Regards, Dave Op za 14 dec. 2019 om 14:33 schreef Jasper den Hertog : > hi Dave, > > I can confirm that there?s a problem with the measurements with ids your > mentioning. > > The creation process never finished for these measurements. The > measurements with the ids 23631303,23631304,23631305 and 23631307 all never > were created. For what I can see now this seems to be a transient problem. > > If you see other measurements with the same problem please report them to > us. > > We will look into the cause of this problem monday, > > greetings, > > Jasper den Hertog > RIPE Atlas team > > > On 13 Dec 2019, at 21:55, Dave . wrote: > > Hi, > > I just started 2 measurements like 10 minutes ago but it does seem > something broke. > > https://atlas.ripe.net/measurements/23631307/#!probes > > Same issue here: > https://atlas.ripe.net/measurements23631307#!probes > > I get to see a spinner instead of the results. > > Thanks, > Dave > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdenhertog at ripe.net Sun Dec 15 20:13:00 2019 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Sun, 15 Dec 2019 20:13:00 +0100 Subject: [atlas] measurement page broken? In-Reply-To: References: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> Message-ID: <375240DF-9A07-4C3C-8809-DEA0DB0C92C3@ripe.net> hi Dave, Thanks for the feedback, I will try to reproduce this tomorrow. This is serious enough to warrant thorough investigation, we should never skip measurement ids, no matter what the response of a particular resolve is. I?ll keep you posted, Greetings, Jasper > On 15 Dec 2019, at 18:28, Dave . wrote: > > Hi Jasper, > > Same result for new tests unfortunately. > > https://atlas.ripe.net/measurements/23650744/#!general > > https://atlas.ripe.net/measurements/23650745/ > > In case you want to try and reproduce it, I am trying to start a one-off DNS test for spotify.com or grc.com and use 74.82.42.42 (Hurricane Electric) as a resolver. The resolver in Amsterdam has an issue currently and I'd like to find out whether other nodes in other locations have the same issue or not. The issue was reported to HE so I guess they will have fixed it soon. > > Regards, > Dave > > > Op za 14 dec. 2019 om 14:33 schreef Jasper den Hertog >: > hi Dave, > > I can confirm that there?s a problem with the measurements with ids your mentioning. > > The creation process never finished for these measurements. The measurements with the ids 23631303,23631304,23631305 and 23631307 all never were created. For what I can see now this seems to be a transient problem. > > If you see other measurements with the same problem please report them to us. > > We will look into the cause of this problem monday, > > greetings, > > Jasper den Hertog > RIPE Atlas team > > >> On 13 Dec 2019, at 21:55, Dave . > wrote: >> >> Hi, >> >> I just started 2 measurements like 10 minutes ago but it does seem something broke. >> >> https://atlas.ripe.net/measurements/23631307/#!probes >> >> Same issue here: >> https://atlas.ripe.net/measurements23631307#!probes >> >> I get to see a spinner instead of the results. >> >> Thanks, >> Dave >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2639 bytes Desc: not available URL: From jdenhertog at ripe.net Mon Dec 16 12:21:22 2019 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 16 Dec 2019 12:21:22 +0100 Subject: [atlas] measurement page broken? In-Reply-To: <375240DF-9A07-4C3C-8809-DEA0DB0C92C3@ripe.net> References: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> <375240DF-9A07-4C3C-8809-DEA0DB0C92C3@ripe.net> Message-ID: <4382F897-DE57-43EB-BC9A-C17C4272DBB0@ripe.net> hi Dave, We?ve dug into this and it turned out that the metadata for DNS measurements wasn?t propagating correctly through our infrastructure, but the measurement data (metadata + results) themselves were not affected. We?ve corrected this behaviour and have stored the metadata correctly so it can be retrieved by users. All the measurement ids you have mentioned in this thread will now return results and metadata. Thanks again for your valuable feedback and happy measuring, greetings, Jasper > On 15 Dec 2019, at 20:13, Jasper den Hertog wrote: > > hi Dave, > > Thanks for the feedback, I will try to reproduce this tomorrow. This is serious enough to warrant thorough investigation, we should never skip measurement ids, no matter what the response of a particular resolve is. > > I?ll keep you posted, > > Greetings, > > Jasper > >> On 15 Dec 2019, at 18:28, Dave . > wrote: >> >> Hi Jasper, >> >> Same result for new tests unfortunately. >> >> https://atlas.ripe.net/measurements/23650744/#!general >> >> https://atlas.ripe.net/measurements/23650745/ >> >> In case you want to try and reproduce it, I am trying to start a one-off DNS test for spotify.com or grc.com and use 74.82.42.42 (Hurricane Electric) as a resolver. The resolver in Amsterdam has an issue currently and I'd like to find out whether other nodes in other locations have the same issue or not. The issue was reported to HE so I guess they will have fixed it soon. >> >> Regards, >> Dave >> >> >> Op za 14 dec. 2019 om 14:33 schreef Jasper den Hertog >: >> hi Dave, >> >> I can confirm that there?s a problem with the measurements with ids your mentioning. >> >> The creation process never finished for these measurements. The measurements with the ids 23631303,23631304,23631305 and 23631307 all never were created. For what I can see now this seems to be a transient problem. >> >> If you see other measurements with the same problem please report them to us. >> >> We will look into the cause of this problem monday, >> >> greetings, >> >> Jasper den Hertog >> RIPE Atlas team >> >> >>> On 13 Dec 2019, at 21:55, Dave . > wrote: >>> >>> Hi, >>> >>> I just started 2 measurements like 10 minutes ago but it does seem something broke. >>> >>> https://atlas.ripe.net/measurements/23631307/#!probes >>> >>> Same issue here: >>> https://atlas.ripe.net/measurements23631307#!probes >>> >>> I get to see a spinner instead of the results. >>> >>> Thanks, >>> Dave >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2639 bytes Desc: not available URL: From gboonie at gmail.com Mon Dec 16 13:18:57 2019 From: gboonie at gmail.com (Dave .) Date: Mon, 16 Dec 2019 13:18:57 +0100 Subject: [atlas] measurement page broken? In-Reply-To: <4382F897-DE57-43EB-BC9A-C17C4272DBB0@ripe.net> References: <6F99C42E-87B2-42EF-AC4B-A5A8E6CBF56C@ripe.net> <375240DF-9A07-4C3C-8809-DEA0DB0C92C3@ripe.net> <4382F897-DE57-43EB-BC9A-C17C4272DBB0@ripe.net> Message-ID: Hi Jasper, Thanks for fixing and giving feedback. Regards, Dave Op ma 16 dec. 2019 om 12:21 schreef Jasper den Hertog : > hi Dave, > > We?ve dug into this and it turned out that the metadata for DNS > measurements wasn?t propagating correctly through our infrastructure, but > the measurement data (metadata + results) themselves were not affected. > > We?ve corrected this behaviour and have stored the metadata correctly so > it can be retrieved by users. All the measurement ids you have mentioned in > this thread will now return results and metadata. > > Thanks again for your valuable feedback and happy measuring, > > greetings, > > Jasper > > On 15 Dec 2019, at 20:13, Jasper den Hertog wrote: > > hi Dave, > > Thanks for the feedback, I will try to reproduce this tomorrow. This is > serious enough to warrant thorough investigation, we should never skip > measurement ids, no matter what the response of a particular resolve is. > > I?ll keep you posted, > > Greetings, > > Jasper > > On 15 Dec 2019, at 18:28, Dave . wrote: > > Hi Jasper, > > Same result for new tests unfortunately. > > https://atlas.ripe.net/measurements/23650744/#!general > > https://atlas.ripe.net/measurements/23650745/ > > In case you want to try and reproduce it, I am trying to start a one-off > DNS test for spotify.com or grc.com and use 74.82.42.42 (Hurricane > Electric) as a resolver. The resolver in Amsterdam has an issue currently > and I'd like to find out whether other nodes in other locations have the > same issue or not. The issue was reported to HE so I guess they will have > fixed it soon. > > Regards, > Dave > > > Op za 14 dec. 2019 om 14:33 schreef Jasper den Hertog >: > >> hi Dave, >> >> I can confirm that there?s a problem with the measurements with ids your >> mentioning. >> >> The creation process never finished for these measurements. The >> measurements with the ids 23631303,23631304,23631305 and 23631307 all never >> were created. For what I can see now this seems to be a transient problem. >> >> If you see other measurements with the same problem please report them to >> us. >> >> We will look into the cause of this problem monday, >> >> greetings, >> >> Jasper den Hertog >> RIPE Atlas team >> >> >> On 13 Dec 2019, at 21:55, Dave . wrote: >> >> Hi, >> >> I just started 2 measurements like 10 minutes ago but it does seem >> something broke. >> >> https://atlas.ripe.net/measurements/23631307/#!probes >> >> Same issue here: >> https://atlas.ripe.net/measurements23631307#!probes >> >> I get to see a spinner instead of the results. >> >> Thanks, >> Dave >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scg at gibbard.org Sun Dec 29 00:20:24 2019 From: scg at gibbard.org (Steve Gibbard) Date: Sat, 28 Dec 2019 15:20:24 -0800 Subject: [atlas] One-off measurements not terminating Message-ID: <2319279C-6702-4106-8682-6C83D9BC7650@gibbard.org> 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 From nils.rodday at unibw.de Sun Dec 29 19:52:01 2019 From: nils.rodday at unibw.de (Nils Rodday) Date: Sun, 29 Dec 2019 19:52:01 +0100 Subject: [atlas] Deletion of erroneously scheduled measurements Message-ID: <0abe2908-4a7b-ed3d-562f-c0e4430636ce@unibw.de> 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.html [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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scg at gibbard.org Mon Dec 30 06:53:17 2019 From: scg at gibbard.org (Steve Gibbard) Date: Sun, 29 Dec 2019 21:53:17 -0800 Subject: [atlas] One-off measurements not terminating In-Reply-To: <2319279C-6702-4106-8682-6C83D9BC7650@gibbard.org> References: <2319279C-6702-4106-8682-6C83D9BC7650@gibbard.org> Message-ID: <101B4546-40F4-49F5-AA67-130CC4C8A037@gibbard.org> An update: I was able to ?delete' my stuck measurements via the API, so they?re stopped now and I?m back up and running for the moment. I also added an API command to my code to ?delete? measurements as soon as the results have been picked up, which I hoped would make this fix sustainable, but so far that doesn?t seem to be doing anything. Perhaps a longer delay is required between creating the measurement and sending the ?delete? command? Thanks, Steve > On Dec 28, 2019, at 3:20 PM, Steve Gibbard wrote: > > 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 > From camin at ripe.net Mon Dec 30 11:24:06 2019 From: camin at ripe.net (Chris Amin) Date: Mon, 30 Dec 2019 11:24:06 +0100 Subject: [atlas] One-off measurements not terminating In-Reply-To: <101B4546-40F4-49F5-AA67-130CC4C8A037@gibbard.org> References: <2319279C-6702-4106-8682-6C83D9BC7650@gibbard.org> <101B4546-40F4-49F5-AA67-130CC4C8A037@gibbard.org> Message-ID: <5a1feafe-2683-79c3-0420-feadf5baceb4@ripe.net> Hi Steve, There was indeed a problem where measurements were not being automatically updated with a "stopped" status. This should now be fixed, but please let me know if you notice any lingering issues. Can you confirm that the issue with manually DELETEing not having an effect still persists? If so, can you give me an example measurement ID? Thanks, Chris Amin RIPE NCC On 30/12/2019 06:53, Steve Gibbard wrote: > An update: I was able to ?delete' my stuck measurements via the API, so they?re stopped now and I?m back up and running for the moment. > > I also added an API command to my code to ?delete? measurements as soon as the results have been picked up, which I hoped would make this fix sustainable, but so far that doesn?t seem to be doing anything. Perhaps a longer delay is required between creating the measurement and sending the ?delete? command? > > Thanks, > Steve > >> On Dec 28, 2019, at 3:20 PM, Steve Gibbard wrote: >> >> 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 >> > > > > > > > From scg at gibbard.org Mon Dec 30 23:37:50 2019 From: scg at gibbard.org (Steve Gibbard) Date: Mon, 30 Dec 2019 14:37:50 -0800 Subject: [atlas] One-off measurements not terminating In-Reply-To: <5a1feafe-2683-79c3-0420-feadf5baceb4@ripe.net> References: <2319279C-6702-4106-8682-6C83D9BC7650@gibbard.org> <101B4546-40F4-49F5-AA67-130CC4C8A037@gibbard.org> <5a1feafe-2683-79c3-0420-feadf5baceb4@ripe.net> Message-ID: <10B428F6-343A-44CD-BB54-D1D2FB99D785@gibbard.org> Thanks Chris! Atlas now looks like it?s behaving the way it did before December 24 ? stopping one-off measurements about five to ten minutes after they start ? which suits my purposes nicely. As far as manual ?deletes' go, it doesn?t look like my efforts to ?delete' measurements as soon as I?ve been able to pick up results are working. There?s no need to fix this on my account ? now that measurements are stopped automatically again, I?ll probably delete the attempted work-around from my code ? but here are details in case they?re otherwise useful: The process www.globaltraceroute.com follows is this: - Create a measurement. Get a measurement ID. - Immediately begin asking for a result every five seconds until it gets one. - Display the result to the user. - New, as of yesterday, send a ?delete? in an attempt to stop the measurement. - Exit Yesterday, the measurements my code attempted to stop this way kept on running indefinitely, just as if it hadn?t sent a ?delete? request. However, if I waited five or ten minutes and ran the function that sends the delete, the measurement would stop. It was a little hard to tell that it was working because measurements would take several minutes to show up as stopped, but when they did the timestamp for the end of the measurement would match the time I ran the ?delete? function. Today, it?a again a little hard to tell what?s doing what. The measurements are all showing as stopped eventually. But if they had been stopped by the delete my script sent, based on what I saw yesterday I assume the stop timestamp would be within a minute or two after the start timestamp. Instead, the delete timestamp is five to ten minutes after the start timestamp, suggesting that they?re continuing to run until Atlas with your latest fix decides they?re finished. Measurement 23732704 is a random example of this ? a measurement that was sent a ?delete? 50 seconds after creation (Dec 30 21:25:14 UTC), but didn?t stop until roughly five minutes later - 2019-12-30 21:30 per https://atlas.ripe.net/measurements/ . Alternatively, if you have a real time view into the Atlas API, you could go to www.globaltraceroute.com and create a measurement. It should then show up immediately in Atlas under the scg at gibbard.org username and go through the process outlined above. Thanks, Steve > On Dec 30, 2019, at 2:24 AM, Chris Amin wrote: > > Hi Steve, > > There was indeed a problem where measurements were not being > automatically updated with a "stopped" status. This should now be fixed, > but please let me know if you notice any lingering issues. > > Can you confirm that the issue with manually DELETEing not having an > effect still persists? If so, can you give me an example measurement ID? > > Thanks, > Chris Amin > RIPE NCC > > On 30/12/2019 06:53, Steve Gibbard wrote: >> An update: I was able to ?delete' my stuck measurements via the API, so they?re stopped now and I?m back up and running for the moment. >> >> I also added an API command to my code to ?delete? measurements as soon as the results have been picked up, which I hoped would make this fix sustainable, but so far that doesn?t seem to be doing anything. Perhaps a longer delay is required between creating the measurement and sending the ?delete? command? >> >> Thanks, >> Steve >> >>> On Dec 28, 2019, at 3:20 PM, Steve Gibbard wrote: >>> >>> 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 >>> >> >> >> >> >> >> >> > > -- Steve Gibbard scg at gibbard.org +1 415 717-7842 (cell) From aleksipirttimaa at protonmail.com Fri Dec 27 23:03:29 2019 From: aleksipirttimaa at protonmail.com (Aleksi Pirttimaa) Date: Fri, 27 Dec 2019 22:03:29 +0000 Subject: [atlas] Probe DHCPv6 support Message-ID: Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 477 bytes Desc: OpenPGP digital signature URL: