From wenqin.shao at telecom-paristech.fr Thu Sep 1 19:14:30 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 1 Sep 2016 19:14:30 +0200 Subject: [atlas] Actual measurement interval much larger than planned Message-ID: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> Dear list, I encountered some cases where the actual time interval between two neighbouring measurements being much larger than the scheduled value. Have you witnessed similar cases? I appreciate explanations on underlying reasons. Here goes an example: from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=1010, probe_ids=[16981], start=1470055258, stop=1470056217) is_success, results = AtlasResultsRequest(**filters).create() if is_success: for mes in results: print mes.get('timestamp', -1) The above code requests some built-in ping measurements (240s interval) made by probe 16981 and prints their timestamps. See below for the execution result: 1470055259 1470055499 1470055978 1470056216 Four measurements are retrieved within the given time range. I noticed that time interval between the 2nd and the 3rd measurement is 479s much larger than the planned value 240s. How come? Many thanks for your attention. Best regards, wenqin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pelsser at unistra.fr Fri Sep 2 09:45:48 2016 From: pelsser at unistra.fr (Cristel Pelsser) Date: Fri, 2 Sep 2016 09:45:48 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> Message-ID: Hi Wenqin, It may be because the probe is busy doing other things. We noticed a high interval between the scheduling and the actual measurement of one-off measurements on busy probes in http://conferences.sigcomm.org/imc/2015/papers/p437.pdf Cristel > On Sep 1, 2016, at 7:14 PM, Wenqin SHAO wrote: > > Dear list, > > I encountered some cases where the actual time interval between two neighbouring measurements being much larger than the scheduled value. > Have you witnessed similar cases? I appreciate explanations on underlying reasons. > > Here goes an example: > > from ripe.atlas.cousteau import AtlasResultsRequest > filters = dict(msm_id=1010, probe_ids=[16981], start=1470055258, stop=1470056217) > is_success, results = AtlasResultsRequest(**filters).create() > if is_success: > for mes in results: > print mes.get('timestamp', -1) > > The above code requests some built-in ping measurements (240s interval) made by probe 16981 and prints their timestamps. See below for the execution result: > > 1470055259 > 1470055499 > 1470055978 > 1470056216 > > Four measurements are retrieved within the given time range. I noticed that time interval between the 2nd and the 3rd measurement is 479s much larger than the planned value 240s. > How come? > > Many thanks for your attention. > > Best regards, > wenqin -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Sep 2 09:53:18 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 2 Sep 2016 09:53:18 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> Message-ID: <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> On 2016-09-01 19:14, Wenqin SHAO wrote: > 1470055259 > 1470055499 > 1470055978 > 1470056216 > > Four measurements are retrieved within the given time range. I noticed that > time interval between the 2nd and the 3rd measurement is 479s much larger > than the planned value 240s. > How come? 479 is almost exactly twice the frequency (240), so it's basically one result skipped. Most likely the probe just didn't execute that measurement (was powered down? rebooting? was refreshing its set of tasks just at the worst time?) Regards, Robert From wenqin.shao at telecom-paristech.fr Fri Sep 2 11:35:55 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Fri, 2 Sep 2016 11:35:55 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> Message-ID: Hi Cristel, hi Robert, Thanks a lot for your feedback. 1. @Cristel, yes, you?re right, I?m aware of this scheduling issue. Indeed, a big part of such ?abnormal? intervals is reasonably ?short?, 55% are between 2 and 4 planned value, among 510 cases seen in 1074 probes traces over a week?s time. 2. As observed by @Robert, most ?abnormal? interval is actually very close to integer times of planned value. If I get your message right, you are indicating that planned measurements can be skipped for the reasons you mentioned and shall kick-off again following the previous timing, even after rebooting? Again many thanks. Regards, wenqin > On 02 Sep 2016, at 09:53, Robert Kisteleki wrote: > > 479 is almost exactly twice the frequency (240), so it's basically one > result skipped. Most likely the probe just didn't execute that measurement > (was powered down? rebooting? was refreshing its set of tasks just at the > worst time?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Sep 2 11:45:24 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 2 Sep 2016 11:45:24 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> Message-ID: <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> > 2. As observed by @Robert, most ?abnormal? interval is actually very close > to integer times of planned value. > If I get your message right, you are indicating that planned measurements > can be skipped for the reasons you mentioned and shall kick-off again > following the previous timing, even after rebooting? Kind of. There's a reasonable expectation that probes will measure with the specified frequency, but reality is that for various reasons you'll not see all the results all the time. Regards, Robert From BECHA at ripe.net Fri Sep 2 12:12:13 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 2 Sep 2016 12:12:13 +0200 Subject: [atlas] Reminder: Join RIPE NCC IXP Tools Hackathon, 22-23 October, Madrid In-Reply-To: <8d18265a-9c58-850c-cf85-1e03853ea93d@ripe.net> References: <56CF163D.5040104@ripe.net> <8d18265a-9c58-850c-cf85-1e03853ea93d@ripe.net> Message-ID: <849eb647-46da-07c2-e959-53022edb51df@ripe.net> Dear all, there's two weeks left before the deadline for the applications! https://atlas.ripe.net/hackathon/ixp-tools/#!application-form Regards, Vesna On 15/08/16 14:58, Vesna Manojlovic wrote: > Dear colleagues, > > together with Euro-IX, Comcast and ISOC, the RIPE NCC is hosting a > hackathon in the weekend before RIPE73, in Madrid. > > For a change, the event will *not* be focused on RIPE Atlas _only_, > but on IXP-related-tools. > > In addition to RIPE Atlas data, we will use RIS data, PeeringDB data, > existing software tools that deal with IXP-data-integration (such as IXP > manager, IXP-Countri-Jedi...) in order to solve some of the challenges > that operators have when making peering decisions, and to illustrate the > impact of IXPs on the Internet routing and connectivity. > > We are looking for designers and developers, students and network > operators, and of course colleagues from IXPs, to work together on > hacking the new & old toolsets and visualizations! > > All source code developed during the hackathon will be publicly licensed > and available on GitHub, and will be free for the entire community to use. > > -------------------- > How to Apply > -------------------- > > Interested? Learn more and apply online today! > > https://atlas.ripe.net/hackathon/ixp-tools/#!application-form > > *The application deadline is 15 September* > > Thanks to our generous sponsors, there is a limited travel funding > available for certain categories of applicants. > > Please find more in this RIPE Labs article: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-ixp-tools-hackathon > > > > We look forward to seeing you there! > > Regards, > Vesna > > From wenqin.shao at telecom-paristech.fr Fri Sep 2 12:20:04 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Fri, 2 Sep 2016 12:20:04 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> Message-ID: Thanks for confirming. The specified frequency is indeed well respected. When there is no data-missing, the interval shift rarely exceed 14s, small compared to 240s the scheduled interval. What intrigues me is that the exact phase/timing is as well kept after power cut and reboot. By the way, can a measurement be as well skipped, as designed behaviour, due to scheduling issues mentioned by @Cristel? Thanks, wenqin > On 02 Sep 2016, at 11:45, Robert Kisteleki wrote: > > >> 2. As observed by @Robert, most ?abnormal? interval is actually very close >> to integer times of planned value. >> If I get your message right, you are indicating that planned measurements >> can be skipped for the reasons you mentioned and shall kick-off again >> following the previous timing, even after rebooting? > > Kind of. There's a reasonable expectation that probes will measure with the > specified frequency, but reality is that for various reasons you'll not see > all the results all the time. > > Regards, > Robert From robert at ripe.net Fri Sep 2 12:57:17 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 2 Sep 2016 12:57:17 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> Message-ID: <3d9a75db-5236-07d4-4695-1fce463e0bf1@ripe.net> On 2016-09-02 12:20, Wenqin SHAO wrote: > Thanks for confirming. The specified frequency is indeed well respected. When there is no data-missing, the interval shift rarely exceed 14s, small compared to 240s the scheduled interval. > What intrigues me is that the exact phase/timing is as well kept after power cut and reboot. The probes have a crontab-like mechanism to remember what they need to do. As long as their clock is more or less ok, they will stick to the pre-allocated times and tasks. > By the way, can a measurement be as well skipped, as designed behaviour, due to scheduling issues mentioned by @Cristel? We're trying to avoid overloading probes, but not everything is under our full control. Some measurements can pile up; Cristel & Randy & co. had a paper about the observed (worst-case) behaviour. Regards, Robert From mkh at rqc.ru Mon Sep 5 14:04:13 2016 From: mkh at rqc.ru (Marat Khalili) Date: Mon, 5 Sep 2016 15:04:13 +0300 Subject: [atlas] Changes in LatencyMon Message-ID: Dear list, LatencyMon changed for me recently with only minimum latency value shown now instead of all three. I wonder if other people see this and what are the reasons behind the change? (Cannot say yet if changes are for better or worse, but I can find no announcement and so suspect that this can be unintentional.) -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Mon Sep 5 14:44:19 2016 From: mcandela at ripe.net (Massimo Candela) Date: Mon, 5 Sep 2016 14:44:19 +0200 Subject: [atlas] Changes in LatencyMon In-Reply-To: References: Message-ID: Hi Marat, Last week I released the last version of LatencyMON, which implements all the improvements since May 2016. One of the feedback I got more often is that users expect latency as a single value and they have difficulty understanding the 3 attempts concept. So by default now it shows only the minimum of the 3, but you can click on the first icon on the right to display all of them. Thanks for using LatencyMON. If you have feedback or questions, drop me an email. Ciao, Massimo Candela > On 05 Sep 2016, at 14:04, Marat Khalili wrote: > > Dear list, > > LatencyMon changed for me recently with only minimum latency value shown now instead of all three. I wonder if other people see this and what are the reasons behind the change? (Cannot say yet if changes are for better or worse, but I can find no announcement and so suspect that this can be unintentional.) > > -- > > With Best Regards, > Marat Khalili > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mir at ripe.net Tue Sep 6 12:08:00 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 6 Sep 2016 12:08:00 +0200 Subject: [atlas] New on RIPE Labs: Using RIPE Atlas to Measure Cloud Connectivity In-Reply-To: <729237d5-bed3-35e8-a685-c89dd15c00e6@ripe.net> References: <729237d5-bed3-35e8-a685-c89dd15c00e6@ripe.net> Message-ID: <9ef0d37d-e8de-50e3-ef7b-71ed3e8a1af3@ripe.net> Dear colleagues, Please find this new article on RIPE Labs describing how to compare connectivity of cloud services using RIPE Atlas measurements. This article has been contributed by Jason Read: https://labs.ripe.net/Members/jason_read/using-ripe-atlas-to-measure-cloud-connectivity?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC From colinj at mx5.org.uk Tue Sep 6 12:41:58 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 6 Sep 2016 11:41:58 +0100 Subject: [atlas] New on RIPE Labs: Using RIPE Atlas to Measure Cloud Connectivity In-Reply-To: <9ef0d37d-e8de-50e3-ef7b-71ed3e8a1af3@ripe.net> References: <729237d5-bed3-35e8-a685-c89dd15c00e6@ripe.net> <9ef0d37d-e8de-50e3-ef7b-71ed3e8a1af3@ripe.net> Message-ID: <095C8B5B-D1C8-4240-A4EE-C5F9F09D5A7E@mx5.org.uk> would be great to have a atlas vm image to install into the cloud for end to end probe connectivity instead of application end point Colin > On 6 Sep 2016, at 11:08, Mirjam Kuehne wrote: > > > Dear colleagues, > > Please find this new article on RIPE Labs describing how to compare > connectivity of cloud services using RIPE Atlas measurements. This > article has been contributed by Jason Read: > > https://labs.ripe.net/Members/jason_read/using-ripe-atlas-to-measure-cloud-connectivity?pk_campaign=labs&pk_kwd=list-atlas > > Kind regards, > Mirjam Kuehne > RIPE NCC > > From romeo.zwart at ripe.net Thu Sep 8 13:26:16 2016 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Thu, 8 Sep 2016 13:26:16 +0200 Subject: [atlas] Data delays on RIPE Atlas Message-ID: Dear colleagues, We are performing some maintenance work on the backend clusters supporting RIPE Atlas. Unexpectedly, this is having an impact on the insertion speed of new data. This means that new data insertion is behind for a few hours. The maintenance work is expected to complete before the end of the day, at which point the backlog of data will be cleared up very quickly. We apologise for any inconvenience caused. Kind regards, Romeo From robert at ripe.net Thu Sep 8 15:43:28 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 8 Sep 2016 15:43:28 +0200 Subject: [atlas] RIPE Atlas APIs Message-ID: Dear colleagues, We've just published a RIPE Labs article about a reminder for the RIPE Atlas API version changes. You can read it here: https://labs.ripe.net/Members/kistel/ripe-atlas-api-changes Regards, Robert Kisteleki RIPE NCC From jdenhertog at ripe.net Thu Sep 8 16:13:03 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Thu, 8 Sep 2016 16:13:03 +0200 Subject: [atlas] API probe search In-Reply-To: <5245d9dd-3339-a45e-ef20-51c0f2990ad9@efes.iucc.ac.il> References: <5245d9dd-3339-a45e-ef20-51c0f2990ad9@efes.iucc.ac.il> Message-ID: <1EAC4BEC-A583-46A8-8F91-5F57374BA8C6@ripe.net> Hank, Sorry for the late reply. Indeed the GUI basically provides a blanket search over all kinds of text fields AND strips AS or ASN from the user input. This is not very convenient and we will improve this, greetings, Jasper den Hertog RIPE Atlas software engineer > On 29 Aug 2016, at 18:11, Hank Nussbacher wrote: > > On 8/29/2016 3:23 PM, Jasper den Hertog wrote: > > Sorry I wasn't more clear. I am referring to the GUI API located at: > https://atlas.ripe.net/probes/ > There is a search box on that page. It even says "filter by id/asn/country/description" Put in there AS222 and see what pops up. > > Regards, > Hank > >> Hi All, >> >> Please note that the v1 API is deprecated. >> >> The latest and greatest query would be: >> >> https://atlas.ripe.net/api/v2/probes/?asn=3333 >> >> and the docs for this live at: >> >> https://atlas.ripe.net/docs/api/v2/manual/probes/queryparameters.html >> >> and >> >> https://atlas.ripe.net/docs/api/v2/reference/#!/probes/Probe_List_GET >> >> Greetings, >> >> Jasper den Hertog >> >> >>> On 29 Aug 2016, at 14:20, Wenqin SHAO > wrote: >>> >>> Hi, >>> >>> Here is an example from the official doc https://atlas.ripe.net/docs/rest/#probe >>> >>> https://atlas.ripe.net/api/v1/probe/?asn=3333 >>> >>> It queries the probes hosted in AS 3333. >>> It works for me. >>> >>> My two cents, >>> wenqin >>> >>>> On 29 Aug 2016, at 13:10, Hank Nussbacher > wrote: >>>> >>>> When searching for specific ASN probes via: >>>> https://atlas.ripe.net/probes/ >>>> and entering a search like "ASxxxx", why does the API ignore the letters AS and respond with probes that have an id of yxxxx or xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific string of ASxxx the response should be only those probes in ASxxx or at the worst also ASxxxy? >>>> >>>> Thanks, >>>> Hank >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From hank at efes.iucc.ac.il Thu Sep 8 17:00:08 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 8 Sep 2016 18:00:08 +0300 Subject: [atlas] API probe search In-Reply-To: <1EAC4BEC-A583-46A8-8F91-5F57374BA8C6@ripe.net> References: <5245d9dd-3339-a45e-ef20-51c0f2990ad9@efes.iucc.ac.il> <1EAC4BEC-A583-46A8-8F91-5F57374BA8C6@ripe.net> Message-ID: <31e6bd3c-f518-97c2-d7a9-982bca7c3c92@efes.iucc.ac.il> On 08/09/2016 17:13, Jasper den Hertog wrote: Thanks! -Hank > Hank, > > Sorry for the late reply. > > Indeed the GUI basically provides a blanket search over all kinds of > text fields AND strips AS or ASN from the user input. This is not very > convenient and we will improve this, > > greetings, > > Jasper den Hertog > RIPE Atlas software engineer > > >> On 29 Aug 2016, at 18:11, Hank Nussbacher > > wrote: >> >> On 8/29/2016 3:23 PM, Jasper den Hertog wrote: >> >> Sorry I wasn't more clear. I am referring to the GUI API located at: >> https://atlas.ripe.net/probes/ >> There is a search box on that page. It even says "filter by >> id/asn/country/description" Put in there AS222 and see what pops up. >> >> Regards, >> Hank >> >>> Hi All, >>> >>> Please note that the v1 API is deprecated. >>> >>> The latest and greatest query would be: >>> >>> https://atlas.ripe.net/api/v2/probes/?asn=3333 >>> >>> and the docs for this live at: >>> >>> https://atlas.ripe.net/docs/api/v2/manual/probes/queryparameters.html >>> >>> and >>> >>> https://atlas.ripe.net/docs/api/v2/reference/#!/probes/Probe_List_GET >>> >>> >>> Greetings, >>> >>> Jasper den Hertog >>> >>> >>>> On 29 Aug 2016, at 14:20, Wenqin SHAO >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Here is an example from the official >>>> doc https://atlas.ripe.net/docs/rest/#probe >>>> >>>> https://atlas.ripe.net/api/v1/probe/?asn=3333 >>>> >>>> It queries the probes hosted in AS 3333. >>>> It works for me. >>>> >>>> My two cents, >>>> wenqin >>>> >>>>> On 29 Aug 2016, at 13:10, Hank Nussbacher >>>> > wrote: >>>>> >>>>> When searching for specific ASN probes via: >>>>> https://atlas.ripe.net/probes/ >>>>> and entering a search like "ASxxxx", why does the API ignore the >>>>> letters AS and respond with probes that have an id of yxxxx or >>>>> xxxxy or ASN yxxxy? Shouldn't it be if I specify a specific >>>>> string of ASxxx the response should be *only *those probes in >>>>> ASxxx or at the worst also ASxxxy? >>>>> >>>>> Thanks, >>>>> Hank >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile.aben at ripe.net Fri Sep 9 13:37:57 2016 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 9 Sep 2016 13:37:57 +0200 Subject: [atlas] Rate limits on Atlas In-Reply-To: References: Message-ID: On 08/09/16 14:01, Anant Shah wrote: > Hi Emile, > > Roya and I are working on a geolocation paper and want to use the atlas > probes to ping target IPs. > > I think I am hitting the rate limit on atlas even with 99 concurrent > measurements. All my measurements now show Forbidden status. Is there a > way to increase the limit? yes, ask the team at atlas at ripe.net (cc-ed). the folks there can extend limits (not unlimited of course, these limits are there for a reason :) ), but would need some info from you: - what is the experiment you'd like to perform - what would you want the new limit to be (and why what you want to do can't be done with the current limits and/or existing measurements) - when does your experiment end (ie. when can we put the limits back to the default) - promise us that you'll acknowledge RIPE Atlas in a paper - send us a link/copy of the paper once it's published (i hope i'm not forgetting things :) ) cheers, emile From wenqin.shao at telecom-paristech.fr Mon Sep 12 15:06:52 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Mon, 12 Sep 2016 15:06:52 +0200 Subject: [atlas] meaning of error message in Ping measurements Message-ID: <8D5DDE33-9BE8-4E38-9D8C-AEE86D685BBD@telecom-paristech.fr> Dear list, Could someone please help me figure out what these error messages in result field of ping measurement mean? - error: sendto failed: Invalid argument (related to name resolve?) - error: sendto failed: Bad file descriptor Many thanks. Best regards, wenqin From philip.homburg at ripe.net Tue Sep 13 10:48:22 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 13 Sep 2016 10:48:22 +0200 Subject: [atlas] meaning of error message in Ping measurements In-Reply-To: <8D5DDE33-9BE8-4E38-9D8C-AEE86D685BBD@telecom-paristech.fr> References: <8D5DDE33-9BE8-4E38-9D8C-AEE86D685BBD@telecom-paristech.fr> Message-ID: <742198d5-f299-91ea-39f5-b93632fba4cd@ripe.net> Hi, > Could someone please help me figure out what these error messages in result field of ping measurement mean? > - error: sendto failed: Invalid argument (related to name resolve?) > - error: sendto failed: Bad file descriptor These are errors returned by the sendto system call on the probe. The sendto(2) manual page on Linux gives a description of when sendto returns those errors. By and large I would say that these errors are not supposed to happen. So this is probably a bug in the probe code. Philip From wenqin.shao at telecom-paristech.fr Tue Sep 13 14:31:14 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Tue, 13 Sep 2016 14:31:14 +0200 Subject: [atlas] meaning of error message in Ping measurements In-Reply-To: <742198d5-f299-91ea-39f5-b93632fba4cd@ripe.net> References: <8D5DDE33-9BE8-4E38-9D8C-AEE86D685BBD@telecom-paristech.fr> <742198d5-f299-91ea-39f5-b93632fba4cd@ripe.net> Message-ID: Hi Philip, Thanks a lot for the explanation. In deed, these error messages rarely appears. My current script just logged their presence and thus is not able to tell which probe is responsible for them at what moment. If the case is of interest to you, I can look into it later. Again, many thanks. Regards, wenqin > On 13 Sep 2016, at 10:48, Philip Homburg wrote: > > Hi, > >> Could someone please help me figure out what these error messages in result field of ping measurement mean? >> - error: sendto failed: Invalid argument (related to name resolve?) >> - error: sendto failed: Bad file descriptor > > These are errors returned by the sendto system call on the probe. > > The sendto(2) manual page on Linux gives a description of when sendto > returns those errors. > > By and large I would say that these errors are not supposed to happen. > So this is probably a bug in the probe code. > > Philip > From mir at ripe.net Wed Sep 14 15:44:57 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 14 Sep 2016 15:44:57 +0200 Subject: [atlas] New on RIPE Labs: Using RIPE Atlas to Monitor Game Service Connectivity In-Reply-To: References: Message-ID: <8e4fe92d-e232-642d-1286-1d96a35ca97f@ripe.net> Dear colleagues, Annika Wickert, a network engineer at a gaming company, describes how she used RIPE Atlas to monitor her company's services and improve their customers' experience - and even decided to become a RIPE Atlas sponsor! https://labs.ripe.net/Members/annika_wickert/using-ripe-atlas-to-monitor-game-service-connectivity Kind regards, Mirjam Kuehne RIPE NCC From yang.yu.list at gmail.com Sun Sep 18 17:19:52 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Sun, 18 Sep 2016 10:19:52 -0500 Subject: [atlas] "Invalid target" error for RFC 1918 space Message-ID: Hi, I got "Invalid target" error when I tried to create a measurement to see how far some RFC 1918 prefixes got propagated (carrier not properly filtering customer announcement). What is considered invalid for each measurement type? Thanks. Yang From bortzmeyer at nic.fr Sun Sep 18 17:22:58 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 18 Sep 2016 17:22:58 +0200 Subject: [atlas] "Invalid target" error for RFC 1918 space In-Reply-To: References: Message-ID: <20160918152258.wsceyd7ziheio3sj@nic.fr> On Sun, Sep 18, 2016 at 10:19:52AM -0500, Yang Yu wrote a message of 9 lines which said: > I got "Invalid target" error when I tried to create a measurement to > see how far some RFC 1918 prefixes got propagated (carrier not > properly filtering customer announcement). What is considered > invalid for each measurement type? Security/privacy reasons: without this rule, people could scan private networks where a probe is hosted. From colinj at mx5.org.uk Sun Sep 18 17:27:34 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Sun, 18 Sep 2016 16:27:34 +0100 Subject: [atlas] "Invalid target" error for RFC 1918 space In-Reply-To: <20160918152258.wsceyd7ziheio3sj@nic.fr> References: <20160918152258.wsceyd7ziheio3sj@nic.fr> Message-ID: <38545635-DFB8-46B2-AB0E-B36C36DAE5A2@mx5.org.uk> would be great to know how this is done, i assume blocked at controller end and not at probe end as i could not see rfc 1918 blocks in probe code This would be so much easier to have vm code for probes so that functionality like this could be enabled for private/vpn network monitoring with custom controller ends. Colin > On 18 Sep 2016, at 16:22, Stephane Bortzmeyer wrote: > > On Sun, Sep 18, 2016 at 10:19:52AM -0500, > Yang Yu wrote > a message of 9 lines which said: > >> I got "Invalid target" error when I tried to create a measurement to >> see how far some RFC 1918 prefixes got propagated (carrier not >> properly filtering customer announcement). What is considered >> invalid for each measurement type? > > Security/privacy reasons: without this rule, people could scan private > networks where a probe is hosted. > From robert at ripe.net Sun Sep 18 17:47:49 2016 From: robert at ripe.net (Robert Kisteleki) Date: Sun, 18 Sep 2016 17:47:49 +0200 Subject: [atlas] "Invalid target" error for RFC 1918 space In-Reply-To: <38545635-DFB8-46B2-AB0E-B36C36DAE5A2@mx5.org.uk> References: <20160918152258.wsceyd7ziheio3sj@nic.fr> <38545635-DFB8-46B2-AB0E-B36C36DAE5A2@mx5.org.uk> Message-ID: Hi, On 2016-09-18 17:27, Colin Johnston wrote: > would be great to know how this is done, i assume blocked at controller > end and not at probe end as i could not see rfc 1918 blocks in probe > code It's enforced in the UI/API as well as in the probe code. The probe part is in libbb/atlas_check_addr.c, available in the published source code. > This would be so much easier to have vm code for probes so that > functionality like this could be enabled for private/vpn network > monitoring with custom controller ends. What would be the reason to make the VMs work differently? And if you had a VM, would you fiddle with the code running on it to make this possible? Regards, Robert > > Colin > >> On 18 Sep 2016, at 16:22, Stephane Bortzmeyer wrote: >> >> On Sun, Sep 18, 2016 at 10:19:52AM -0500, >> Yang Yu wrote >> a message of 9 lines which said: >> >>> I got "Invalid target" error when I tried to create a measurement to >>> see how far some RFC 1918 prefixes got propagated (carrier not >>> properly filtering customer announcement). What is considered >>> invalid for each measurement type? >> >> Security/privacy reasons: without this rule, people could scan private >> networks where a probe is hosted. >> > > > From colinj at mx5.org.uk Sun Sep 18 17:56:44 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Sun, 18 Sep 2016 16:56:44 +0100 Subject: [atlas] "Invalid target" error for RFC 1918 space In-Reply-To: References: <20160918152258.wsceyd7ziheio3sj@nic.fr> <38545635-DFB8-46B2-AB0E-B36C36DAE5A2@mx5.org.uk> Message-ID: <2CC82D57-BDC5-48FA-AEA8-925949129224@mx5.org.uk> would be useful if VM probes could built for private networks to be scanned on a per user basis, would make is so much easier and cheaper to monitor internal vm clouds. vm functionality as said before would be great for cost saving over physical hardware and also useful to test end probe user projects to add functionality for different types of service monitoring. glad this thread prompted more debate :) Colin > On 18 Sep 2016, at 16:47, Robert Kisteleki wrote: > > Hi, > > On 2016-09-18 17:27, Colin Johnston wrote: >> would be great to know how this is done, i assume blocked at controller >> end and not at probe end as i could not see rfc 1918 blocks in probe >> code > > It's enforced in the UI/API as well as in the probe code. The probe part is > in libbb/atlas_check_addr.c, available in the published source code. > >> This would be so much easier to have vm code for probes so that >> functionality like this could be enabled for private/vpn network >> monitoring with custom controller ends. > > What would be the reason to make the VMs work differently? And if you had a > VM, would you fiddle with the code running on it to make this possible? > > Regards, > Robert > >> >> Colin >> >>> On 18 Sep 2016, at 16:22, Stephane Bortzmeyer wrote: >>> >>> On Sun, Sep 18, 2016 at 10:19:52AM -0500, >>> Yang Yu wrote >>> a message of 9 lines which said: >>> >>>> I got "Invalid target" error when I tried to create a measurement to >>>> see how far some RFC 1918 prefixes got propagated (carrier not >>>> properly filtering customer announcement). What is considered >>>> invalid for each measurement type? >>> >>> Security/privacy reasons: without this rule, people could scan private >>> networks where a probe is hosted. >>> >> >> >> > From mgalante at ripe.net Mon Sep 19 11:30:55 2016 From: mgalante at ripe.net (Michela Galante) Date: Mon, 19 Sep 2016 11:30:55 +0200 Subject: [atlas] Fifteen new RIPE Atlas anchors - including the first IPv4-only anchor Message-ID: Dear colleagues, Fifteen new RIPE Atlas anchors have been activated since our last announcement in June, bringing the total number to 216: - us-abn-as54054, hosted by Deteque LLC in Ashburn, United States - us-sgu-as46309, hosted by Gartner Inc in Saint George, United States - lu-kay-as35733, hosted by EURid VZW in Kayl, Luxembourg - de-ham-as35258, hosted by akquinet Outsourcing in Hamburg, Germany - ua-iev-as24725, hosted by Hostmaster LLC in Kiev, Ukraine - ca-wnp-as18451, hosted by les.net in Winnipeg, Canada - de-dus-as12676, hosted by HKN GmbH in D?sseldorf, Germany - uk-lon-as34587, hosted by bet365 in London, United Kingdom - us-lax-as15133, hosted by Verizon Digital Media in Los Angeles, United States - us-lwc-as2495, hosted by KanREN Inc in Lawrence, United States - lb-bey-as12812, hosted by the American University of Beirut in Beirut, Lebanon (IPv4-only anchor) - pg-pom-as17828, hosted by Telikom PNG (sponsored by APNIC) in Port Moresby, Papua New Guinea - ch-zrh-as9092, hosted by Open Systems in Zurich, Switzerland - nl-ams-as34106, hosted by TMG/Telegraaf in Amsterdam, Netherlands - dk-hje-as39642, hosted by WNB ApS in H?jer, Denmark You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas anchors online: https://atlas.ripe.net/anchors/list/ As a follow-up to some discussion on this list, we wanted to reiterate that we made the decision to support IPv4-only anchors because the goal of RIPE Atlas is to measure as much of the Internet as possible, and right now, that includes IPv4-only networks. We also believe that measuring networks before and after they enable IPv6 provides useful data. IPv4-only anchors are clearly marked as such, and we will implement checks to ensure these anchors become IPv6-capable as soon as their ASNs begin announcing IPv6. In the meantime, the RIPE NCC will continue to actively promote IPv6 deployment through our training courses, IPv6 Act Now website, IPv6 Roadshows and other programs, and our IPv6 Program Manager will follow up with any hosts requesting an IPv4-only anchor to help them in any way possible. We believe that supporting IPv4-only anchors will provide a more comprehensive understanding of the Internet and that the entire Internet community will benefit from more measurement data. You can learn more in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ipv4-only-ripe-atlas-anchors-now-supported Interested in hosting a RIPE Atlas anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa in order to add more geographical diversity to the measurement data. There are several organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, or for any other questions, please contact us at atlas at ripe.net And don?t forget to let us know if you?re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From zakaria.alqudah at gmail.com Tue Sep 27 11:27:41 2016 From: zakaria.alqudah at gmail.com (Zakaria Al-Qudah) Date: Tue, 27 Sep 2016 11:27:41 +0200 Subject: [atlas] Initiating a TCP, UDP, and ICMP traceroutes from the same probe at the same time Message-ID: Hi Folks, I am planning an experiment where I need each probe to perform TCP, UDP, and ICMP traceroutes at the same time. I could not see how I can do it using the Ripe Atlas website. Is there any way to do it? Best regards, Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From michabailey at gmail.com Tue Sep 27 16:46:17 2016 From: michabailey at gmail.com (Micha Bailey) Date: Tue, 27 Sep 2016 17:46:17 +0300 Subject: [atlas] Initiating a TCP, UDP, and ICMP traceroutes from the same probe at the same time In-Reply-To: References: Message-ID: AFAIK there is no way to force several measurements to be performed simultaneously. You can request a specific probe for immediate execution, but that doesn't guarantee that they will all be performed simultaneously or immediately -- the scheduler will have them be performed imminently. As far as I know what it sounds like you're asking for does not currently exist as a possibility. On Tuesday, September 27, 2016, Zakaria Al-Qudah wrote: > Hi Folks, > > I am planning an experiment where I need each probe to perform TCP, UDP, > and ICMP traceroutes at the same time. I could not see how I can do it > using the Ripe Atlas website. Is there any way to do it? > > Best regards, > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Fri Sep 30 09:50:41 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Fri, 30 Sep 2016 09:50:41 +0200 Subject: [atlas] =?utf-8?q?Making_public_probes=E2=80=99_IP_addresses_publ?= =?utf-8?q?ic_in_web_interface?= Message-ID: <1d110de2-f7dd-d47f-df4f-7319271e2d32@ripe.net> Hello, We made a change a few weeks ago to the RIPE Atlas web interface to align it more closely with the API. As a result, you can now see the IP addresses for public probes, regardless of whether you are a logged in user or not. This information is displayed on the public probes? detailed information pages, under the ?Network? tab. Previously, public probes' IP addresses were not shown, even for logged in users. Nothing has changed in the API or the web interface for probes that are not shared publicly. We understand that some of you were surprised by this change and we apologise for not communicating it earlier. However, I want to make it clear that the IP addresses of public probes have always been available via the API, whether you are a logged in user or not. We decided to include it via the web interface so that our users could access the same information regardless of which interface they decide to use. RIPE Atlas is meant to be a public platform that openly provides data to everyone interested. In this spirit, we encourage everyone to make their probes public. However, if you decide that you *don?t* want to share your probe publicly, you can change this setting by going to your probe?s detailed information page (go to "My Atlas" and click on your probe?s ID), clicking on the ?Edit? button under the ?General Information? tab, and deselecting the ?Shared Publicly? box. Please note that personal information such as MAC addresses and email addresses will never be shown, regardless of whether you decide to share your probe publicly or not. You can learn more about what information is made public in RIPE Atlas in this RIPE Labs article: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public Please let us know if you have any questions or concerns. Regards, Andreas Strikos RIPE NCC From robert at ripe.net Fri Sep 30 10:59:01 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 30 Sep 2016 10:59:01 +0200 Subject: [atlas] Initiating a TCP, UDP, and ICMP traceroutes from the same probe at the same time In-Reply-To: References: Message-ID: <8c29a2d4-ba97-43c8-f255-469aa8b72ba3@ripe.net> On 2016-09-27 11:27, Zakaria Al-Qudah wrote: > Hi Folks, > > I am planning an experiment where I need each probe to perform TCP, UDP, and ICMP traceroutes at the same time. I could not see how I can do it using the Ripe Atlas website. Is there any way to do it? > > Best regards, Hello, There's no guarantee to execute them "at the same time", however you can align them pretty close to each other (maybe even in parallel) if you use one-offs and specify them together. Regards, Robert From jomat+ripeatlasml at jmt.gr Fri Sep 30 14:18:27 2016 From: jomat+ripeatlasml at jmt.gr (Johannes Matheis) Date: Fri, 30 Sep 2016 12:18:27 +0000 Subject: [atlas] Inconsistent system tags Message-ID: Hello, I got IPv6 connectivity for my probe 4365 a few days ago (2016-09-26) when I first noticed the system tag "IPv6 Doesn't Work". As the system tags aren't updated more often than every four hours I started some successful IPv6 measurements on that probe and settled back for four days. Now the probe is still flagged as IPv6 not working. In the meantime I noticed the tag "v2" but the general information tab tells me the system architecture is probev1? Actually I don't know if it's a v1 or v2, but it's still an old Lantronix one, so it's not completely wrong :-) Is there a possibility to re-trigger the assignment of the system tags for this probe or some other solution? Thanks! jomat From robert at ripe.net Fri Sep 30 14:54:38 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 30 Sep 2016 14:54:38 +0200 Subject: [atlas] Inconsistent system tags In-Reply-To: References: Message-ID: Johannes, On 2016-09-30 14:18, Johannes Matheis wrote: > Hello, > > I got IPv6 connectivity for my probe 4365 a few days ago (2016-09-26) > when I first noticed the system tag "IPv6 Doesn't Work". As the system > tags aren't updated more often than every four hours I started some > successful IPv6 measurements on that probe and settled back for four > days. Now the probe is still flagged as IPv6 not working. In the There is evidence of v6 failing around 26 September, but the successes after don't seem to be recognised. We'll check why that is. > meantime I noticed the tag "v2" but the general information tab tells > me the system architecture is probev1? Actually I don't know if it's > a v1 or v2, but it's still an old Lantronix one, so it's not completely > wrong :-) All lantronix probes have the "probev1" architecture; even though the v2 probes have more memory, they run the same code and have the same architecture. So this is correct :-) > Is there a possibility to re-trigger the assignment of the system tags > for this probe or some other solution? This will happen automatically, once we understand (and possibly fix) the reason. Please bear with us. Thank you for reporting this! Robert > Thanks! > jomat > > > From me at anuragbhatia.com Fri Sep 30 19:54:52 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 30 Sep 2016 23:24:52 +0530 Subject: [atlas] SSL error on OpenIPMap Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone. Is it just me or anyone else getting SSL error on OpenIPMap? I can see that SSL cert of atlas.ripe.net is valid but when we open OpenIP Map, it calls one specific map image from fastly on HTTP resulting in "mixed content" making Chrome to throw SSL error. This is the URL of that image:http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png It does seems to be available on https already and so probably someone at RIPE need to update URL to call https in URL and avoid the false positive it's giving. Thanks. - -- Anurag Bhatiaanuragbhatia.com -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.5.2 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJX7qbdCRDAbdUkJF5Y4gAAP7oP/R+c7QMQEIt7c0/fLnKx IrvoSxS0RlivGHQBcQY4DcQvXNU0SsBdjUTG3hOJP/OyCERG9Uar8xRFXKAB LHrUGPa9rGdxHtJFJYL0fgKc0o0aELBkaot3unJPBRwGtp5Acyfx3Yv9CUF+ fqxq27tRnRtXklqVfYw5aWC20CC4EHEme3vv0+QsdasJ0s1mi1zehI1c60yI RQqZ35MaB9flyMyxU1L2CaKHh0BnZs0ssSxGsr/s2cfqhfu5KPzagi/obsEs 6mhwtkTPD1Y/649QAzs2E3vpZ83tn8fkExU54hHznpBy4QmNIAx7pnlwtOrX 8ou7Rn1Yt7V5NiSHGkr31sPJfMfHXErZ6NAl/Z7uPcs9+ofAkAEBh5H7pINr BFwZzX6DsqNiq1Q+F9sU385D5144Y4YE/vDIDXYXhSgbHv9NeqIph7Ceitt9 Ap4wx7eOh/8ONLddUdqf4/M0m9ORsFc4fRAhFkLCzLdUlXpDqAGGgxSFIcg4 NiInbdyZCO1Ula7TQCPR0qtTDJQ75w93wj5STM2uZjlVd5K6QUB4bmz8S/QX oEMLOSmjcWybQH+dBSJ25VVynCu7sRkSUyhyE2wwrb2adDw8pS0QMG5cyjhZ DX+XP9KGoFi6xYFCQypXO+bkSsh84OBKrxo+fFfznFTYFkDZ6yae/ZKSfC/o urP4 =coGp -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile.aben at ripe.net Fri Sep 30 20:59:00 2016 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 30 Sep 2016 20:59:00 +0200 Subject: [atlas] SSL error on OpenIPMap In-Reply-To: References: Message-ID: Hi Anurag, On 30/09/16 19:54, Anurag Bhatia wrote: > Hello everyone. > > > > Is it just me or anyone else getting SSL error on OpenIPMap? I can see that SSL cert of atlas.ripe.net is valid but when we open OpenIP Map, it calls one specific map image from fastly on HTTP resulting in "mixed content" making Chrome to throw SSL error. > > This is the URL of that image: > http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png > > > > It does seems to be available on https already and so probably someone at RIPE need to update URL to call https in URL and avoid the false positive it's giving. > it did work for me in chrome. i saw warnings in console, but nothing that would stop the OpenIPMap pages from functioning. that said, i changed tile loading from http to https , so that shouldn't be a problem anymore. Note that OpenIPMap is a prototype, and is scheduled to be replaced by a production version. cheers, emile