From matteo at bonora.eu Sat Nov 1 21:51:32 2014 From: matteo at bonora.eu (Matteo Bonora) Date: Sat, 01 Nov 2014 20:51:32 +0000 Subject: [atlas] Atlas system tags Message-ID: Hello, I have an atlas probe (#14602) connected to my home network. It has fully working IPv4 and IPv6 connectivity, but the only system tags assigned to it are "V3" and "IPv4 Works". Why the tags "Resolves A Correctly", "Resolves AAAA Correctly" and "IPv6 Works" are not assigned to my probe? I have read the requisites for these tags into the documentation and I didn't find anything that the probe should not be able to do. There is something I can do to verify and fix the situation? Thanks in advance for your help! Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.massen at restena.lu Mon Nov 3 15:25:06 2014 From: gilles.massen at restena.lu (Gilles Massen) Date: Mon, 03 Nov 2014 14:25:06 +0000 Subject: [atlas] New measurement UI Message-ID: <54579042.4000307@restena.lu> Hello, I'd like to give a bit of early feedback to the new atlas UI. All in all it's nice, but I have trouble with the measurement creation in two points: Selection of probes: I like the selecting via map, but usually something like "50 out of central europe" is good enough. If that is possible, how would you do that? A bug about credit evaluation: trying to create a measurement with DNS6 queries for hostname.bind CH TXT with more than a handful of probes (roughly 50-70 probes I guess) fails as the interfaces believes this to require over 1000000 credits. As for map representation (which I use quite often), I think I prefer the old map without aggregation. But that's quite personal. BTW, the new one seems to fail on response diversity for DNS. best, Gilles From the.lists at mgm51.com Mon Nov 3 17:01:16 2014 From: the.lists at mgm51.com (Mike.) Date: Mon, 03 Nov 2014 11:01:16 -0500 Subject: [atlas] Measurement UI beta Message-ID: <201411031101160582.00A72187@smtp.24cl.home> I just had a chance to look at the beta for the MeasurementUI. Is there a specfic reason why RIPE is using the very low-contrast light grey letters on a white background? Why make it more difficult to read? From modonovan at btireland.net Tue Nov 4 17:19:45 2014 From: modonovan at btireland.net (Mick O'Donovan [BT Ireland]) Date: Tue, 4 Nov 2014 16:19:45 +0000 Subject: [atlas] [mat-wg] New on RIPE Labs: New RIPE Atlas Measurements User Interface In-Reply-To: <5450EDB0.1030705@ripe.net> References: <544FB563.5030908@ripe.net> <5450E571.1010906@jacobs-university.de> <5450EDB0.1030705@ripe.net> Message-ID: <20141104161945.GA17140@supporthost.esat.net.esat.net> Well done to all involved! Mick On Wed, Oct 29, 2014 at 02:37:52PM +0100, Vesna Manojlovic wrote: > Updated roadmap can be found here: > http://roadmap.ripe.net/ripe-atlas/ > > Please take a look, and let me (or the list) know of any other new > features you want us to add in the future. > > Regards, > Vesna > > From matteo at bonora.eu Wed Nov 5 16:10:14 2014 From: matteo at bonora.eu (Matteo Bonora) Date: Wed, 05 Nov 2014 15:10:14 +0000 Subject: [atlas] Built-in IPv6 measurements not working Message-ID: Hello, I have noticed that my probe (#14602) doesn't perform the IPv6 built-in measurements since about 5 months. The probe has working IPv6 connectivity, so I can't understand where is the problem. Anyone has an idea about what can I do to solve this? (below you can see some graphs of my probe's measurements. The brief packet loss on IPv4 was due to a temporary network outage) Thanks for your help! Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 16.01.07.png Type: image/png Size: 78152 bytes Desc: not available URL: From albyva at empire.org Thu Nov 6 13:03:28 2014 From: albyva at empire.org (AlbyVA) Date: Thu, 6 Nov 2014 07:03:28 -0500 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: Matteo: Are you 100% sure the probe has a v6 address or if v6 is working overall? Do you have native v6 or tunneled? Not that it matters, other than the tunnel could be down. I also don't see any v6 tags on your probe's page (ie: v6 Works or Resolves AAAA Correctly). Here is my probe with v6 working and I've got a v6 tunnel running: https://atlas.ripe.net/probes/10378/ What is your probe's v6 address? Maybe we can all see if it's pingable. On Wed, Nov 5, 2014 at 10:10 AM, Matteo Bonora wrote: > Hello, > > I have noticed that my probe (#14602) doesn't perform the IPv6 built-in > measurements since about 5 months. > > The probe has working IPv6 connectivity, so I can't understand where is > the problem. > > Anyone has an idea about what can I do to solve this? > > (below you can see some graphs of my probe's measurements. The brief > packet loss on IPv4 was due to a temporary network outage) > > Thanks for your help! > > Matteo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 16.01.07.png Type: image/png Size: 78152 bytes Desc: not available URL: From matteo at bonora.eu Thu Nov 6 13:49:33 2014 From: matteo at bonora.eu (Matteo Bonora) Date: Thu, 6 Nov 2014 13:49:33 +0100 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: Yes, I'm sure the probe has a v6 address because it is displayed into the "Network Information" tab and I'm 100% sure that v6 is working because all the devices (computers, smartphones, etc.) connected to the same network are using v6 without problems. My v6 network is tunneled. I know that the tunnel is up because now I'm using v6 to surf the net and send you this email. I too noticed the missing system tags. Some days ago I sent a message about this issue but unfortunately I got no answer. My probe's v6 address is: 2001:1418:1a5:0:6666:b3ff:feb0:ef68 The address is also displayed when clicking on my probe on the map at this URL https://atlas.ripe.net/results/maps/network-coverage/ Thanks for your help! Matteo On Thu, Nov 6, 2014 at 1:03 PM, AlbyVA wrote: > > > Matteo: > > Are you 100% sure the probe has a v6 address or if v6 is working overall? > Do you have native v6 or tunneled? Not that it matters, other than the > tunnel could be down. > I also don't see any v6 tags on your probe's page (ie: v6 Works or > Resolves AAAA Correctly). > > Here is my probe with v6 working and I've got a v6 tunnel running: > https://atlas.ripe.net/probes/10378/ > > What is your probe's v6 address? Maybe we can all see if it's pingable. > > On Wed, Nov 5, 2014 at 10:10 AM, Matteo Bonora wrote: > >> Hello, >> >> I have noticed that my probe (#14602) doesn't perform the IPv6 built-in >> measurements since about 5 months. >> >> The probe has working IPv6 connectivity, so I can't understand where is >> the problem. >> >> Anyone has an idea about what can I do to solve this? >> >> (below you can see some graphs of my probe's measurements. The brief >> packet loss on IPv4 was due to a temporary network outage) >> >> Thanks for your help! >> >> Matteo >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 16.01.07.png Type: image/png Size: 78152 bytes Desc: not available URL: From matteo at bonora.eu Thu Nov 6 14:02:51 2014 From: matteo at bonora.eu (Matteo Bonora) Date: Thu, 6 Nov 2014 14:02:51 +0100 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: I can add that with a tcpdump on the gateway I can see incoming and outgoing v6 traffic to/from the probe. The host that I can see regularly communicate with my probe is ctr-ams13.atlas.ripe.net. Matteo On Thu, Nov 6, 2014 at 1:49 PM, Matteo Bonora wrote: > Yes, I'm sure the probe has a v6 address because it is displayed into the > "Network Information" tab and I'm 100% sure that v6 is working because all > the devices (computers, smartphones, etc.) connected to the same network > are using v6 without problems. > > My v6 network is tunneled. I know that the tunnel is up because now I'm > using v6 to surf the net and send you this email. > > I too noticed the missing system tags. Some days ago I sent a message > about this issue but unfortunately I got no answer. > > My probe's v6 address is: 2001:1418:1a5:0:6666:b3ff:feb0:ef68 > The address is also displayed when clicking on my probe on the map at this > URL https://atlas.ripe.net/results/maps/network-coverage/ > > Thanks for your help! > > Matteo > > > On Thu, Nov 6, 2014 at 1:03 PM, AlbyVA wrote: > >> >> >> Matteo: >> >> Are you 100% sure the probe has a v6 address or if v6 is working >> overall? >> Do you have native v6 or tunneled? Not that it matters, other than the >> tunnel could be down. >> I also don't see any v6 tags on your probe's page (ie: v6 Works or >> Resolves AAAA Correctly). >> >> Here is my probe with v6 working and I've got a v6 tunnel running: >> https://atlas.ripe.net/probes/10378/ >> >> What is your probe's v6 address? Maybe we can all see if it's pingable. >> >> On Wed, Nov 5, 2014 at 10:10 AM, Matteo Bonora wrote: >> >>> Hello, >>> >>> I have noticed that my probe (#14602) doesn't perform the IPv6 built-in >>> measurements since about 5 months. >>> >>> The probe has working IPv6 connectivity, so I can't understand where is >>> the problem. >>> >>> Anyone has an idea about what can I do to solve this? >>> >>> (below you can see some graphs of my probe's measurements. The brief >>> packet loss on IPv4 was due to a temporary network outage) >>> >>> Thanks for your help! >>> >>> Matteo >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 16.01.07.png Type: image/png Size: 78152 bytes Desc: not available URL: From d.baeza at tvt-datos.es Thu Nov 6 14:42:35 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Thu, 06 Nov 2014 14:42:35 +0100 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: <545B7ACB.2050003@tvt-datos.es> Hi, 2001:1418:1a5:0:6666:b3ff:feb0:ef68 is reachable from here! (AS199952) El 06/11/2014 13:49, Matteo Bonora escribi?: > Yes, I'm sure the probe has a v6 address because it is displayed into > the "Network Information" tab and I'm 100% sure that v6 is working > because all the devices (computers, smartphones, etc.) connected to the > same network are using v6 without problems. > > My v6 network is tunneled. I know that the tunnel is up because now I'm > using v6 to surf the net and send you this email. > > I too noticed the missing system tags. Some days ago I sent a message > about this issue but unfortunately I got no answer. > > My probe's v6 address is: 2001:1418:1a5:0:6666:b3ff:feb0:ef68 > The address is also displayed when clicking on my probe on the map at > this URL https://atlas.ripe.net/results/maps/network-coverage/ > > Thanks for your help! > > Matteo > > On Thu, Nov 6, 2014 at 1:03 PM, AlbyVA > wrote: > > > > Matteo: > > Are you 100% sure the probe has a v6 address or if v6 is working > overall? > Do you have native v6 or tunneled? Not that it matters, other than > the tunnel could be down. > I also don't see any v6 tags on your probe's page (ie: v6 Works or > Resolves AAAA Correctly). > > Here is my probe with v6 working and I've got a v6 tunnel running: > https://atlas.ripe.net/probes/10378/ > > What is your probe's v6 address? Maybe we can all see if it's > pingable. > > On Wed, Nov 5, 2014 at 10:10 AM, Matteo Bonora > wrote: > > Hello, > > I have noticed that my probe (#14602) doesn't perform the IPv6 > built-in measurements since about 5 months. > > The probe has working IPv6 connectivity, so I can't understand > where is the problem. > > Anyone has an idea about what can I do to solve this? > > (below you can see some graphs of my probe's measurements. The > brief packet loss on IPv4 was due to a temporary network outage) > > Thanks for your help! > > Matteo > > > -- Daniel Baeza Centro de Observaci?n de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza at tvt-datos.es -- [Atenci?n] La informaci?n contenida en este e-mail es confidencial, privilegiada y est? dirigida exclusivamente a su destinatario. Cualquier revisi?n, difusi?n, distribuci?n o copiado de este mensaje sin autorizaci?n del propietario est? prohibido. Si ha recibido este e-mail por error por favor b?rrelo y env?e un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario. From philip.homburg at ripe.net Thu Nov 6 15:13:34 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 06 Nov 2014 14:13:34 +0000 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: <545B820E.1030901@ripe.net> Hi Matteo, On 2014/11/06 12:49 , Matteo Bonora wrote: > Yes, I'm sure the probe has a v6 address because it is displayed into > the "Network Information" tab and I'm 100% sure that v6 is working > because all the devices (computers, smartphones, etc.) connected to the > same network are using v6 without problems. It seems to be problem that is internal to the probe. At this moment, I have no idea what it is exactly. But there is no reason to assume that it has much to do with basic network connectivity. Philip From matteo at bonora.eu Thu Nov 6 15:31:34 2014 From: matteo at bonora.eu (Matteo Bonora) Date: Thu, 6 Nov 2014 15:31:34 +0100 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: <545B820E.1030901@ripe.net> References: <545B820E.1030901@ripe.net> Message-ID: Hi Philip, if the problem is internal to the probe, what can we to to solve it? There is a procedure that I can do from my side to "reset" the the probe itself? Maybe is for the same reason that the user-defined v6 measurements don't run on my probe or the system tags aren't shown on the probe's general information page. Thank you Matteo On Thu, Nov 6, 2014 at 3:13 PM, Philip Homburg wrote: > Hi Matteo, > > On 2014/11/06 12:49 , Matteo Bonora wrote: > > Yes, I'm sure the probe has a v6 address because it is displayed into > > the "Network Information" tab and I'm 100% sure that v6 is working > > because all the devices (computers, smartphones, etc.) connected to the > > same network are using v6 without problems. > > It seems to be problem that is internal to the probe. At this moment, I > have no idea what it is exactly. But there is no reason to assume that > it has much to do with basic network connectivity. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From albyva at empire.org Fri Nov 7 16:10:08 2014 From: albyva at empire.org (AlbyVA) Date: Fri, 7 Nov 2014 10:10:08 -0500 Subject: [atlas] Built-in IPv6 measurements not working In-Reply-To: References: Message-ID: Definitely not a v6 routing/addressing issue. I guess it's all the probe. I suppose the RIPE folks will have to look into this one. --- 2001:1418:1a5:0:6666:b3ff:feb0:ef68 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 149.769/151.367/152.520/1.166 ms On Thu, Nov 6, 2014 at 7:49 AM, Matteo Bonora wrote: > Yes, I'm sure the probe has a v6 address because it is displayed into the > "Network Information" tab and I'm 100% sure that v6 is working because all > the devices (computers, smartphones, etc.) connected to the same network > are using v6 without problems. > > My v6 network is tunneled. I know that the tunnel is up because now I'm > using v6 to surf the net and send you this email. > > I too noticed the missing system tags. Some days ago I sent a message > about this issue but unfortunately I got no answer. > > My probe's v6 address is: 2001:1418:1a5:0:6666:b3ff:feb0:ef68 > The address is also displayed when clicking on my probe on the map at this > URL https://atlas.ripe.net/results/maps/network-coverage/ > > Thanks for your help! > > Matteo > > On Thu, Nov 6, 2014 at 1:03 PM, AlbyVA wrote: > >> >> >> Matteo: >> >> Are you 100% sure the probe has a v6 address or if v6 is working >> overall? >> Do you have native v6 or tunneled? Not that it matters, other than the >> tunnel could be down. >> I also don't see any v6 tags on your probe's page (ie: v6 Works or >> Resolves AAAA Correctly). >> >> Here is my probe with v6 working and I've got a v6 tunnel running: >> https://atlas.ripe.net/probes/10378/ >> >> What is your probe's v6 address? Maybe we can all see if it's pingable. >> >> On Wed, Nov 5, 2014 at 10:10 AM, Matteo Bonora wrote: >> >>> Hello, >>> >>> I have noticed that my probe (#14602) doesn't perform the IPv6 built-in >>> measurements since about 5 months. >>> >>> The probe has working IPv6 connectivity, so I can't understand where is >>> the problem. >>> >>> Anyone has an idea about what can I do to solve this? >>> >>> (below you can see some graphs of my probe's measurements. The brief >>> packet loss on IPv4 was due to a temporary network outage) >>> >>> Thanks for your help! >>> >>> Matteo >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2014-11-05 at 16.01.07.png Type: image/png Size: 78152 bytes Desc: not available URL: From mgalante at ripe.net Wed Nov 12 11:49:15 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 12 Nov 2014 11:49:15 +0100 Subject: [atlas] skHosting.eu (SK) has joined RIPE Atlas anchors Message-ID: <54754E21-A5F8-49BF-8FB0-5BE739A325A3@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sk-bts-as201702 and it is hosted by skHosting.eu in Bratislava, Slovakia. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurasble features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From lhestina at ripe.net Fri Nov 14 17:28:35 2014 From: lhestina at ripe.net (Lia Hestina) Date: Fri, 14 Nov 2014 17:28:35 +0100 Subject: [atlas] KazNIC Organization (KZ) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called kz-plx-as21282 and it is hosted by KazNIC Organization in Semey, Kazakhstan. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: From mgalante at ripe.net Mon Nov 17 13:53:01 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 17 Nov 2014 13:53:01 +0100 Subject: [atlas] Booking.com (NL and UK) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that two RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors are nl-ams-as43996 located in Amsterdam, Netherlands and uk-slo-as43996 located in Slough, United Kingdom, both hosted by Booking.com. Congratulations to Booking.com for bringing their two anchors online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mgalante at ripe.net Mon Nov 17 16:40:37 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 17 Nov 2014 16:40:37 +0100 Subject: [atlas] Lanka Education & Research (LK) has joined RIPE Atlas anchors Message-ID: <9D723918-1AC5-41FD-9BF3-360640E617DD@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called lk-cmb-as38229 and it is hosted by Lanka Education & Research in Colombo, Sri Lanka. This is the first of ten anchors that APNIC will sponsor. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From dquinn at ripe.net Mon Nov 17 17:56:43 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 17 Nov 2014 17:56:43 +0100 Subject: [atlas] Atlas Sagan library and UDP tarceroute results: bug or feature? In-Reply-To: References: Message-ID: <546A28CB.1030208@ripe.net> On 31/10/14 15:15, Jen Linkova wrote: I?ve just found that using Sagan library for analyzing UDP traceroute measurement results may produce incorrect results: ?target_responded? variable is not be set to ?True? if the source address of the traceroute reply is not the target address of the traceroute, but any other address that belongs to the node. Hi there, and sorry about the late reply on this. I?m the primary author on Sagan and I?ve been on vacation for the past couple weeks. This email was the topic of some debate in the office and we?ve arrived at a few suggestions that I?d like some community feedback on if anyone has two cents to throw this way: The proposal is to remove |target_responded| and introduce two new properties: * A boolean named |destination_ip_responded| to reflect the current behaviour of |target_responded| * A boolean named something like |last_hop_responded| or just |target_responded| representing whether the last hop was a response at all. What do you (and the others on this list) think of this? Making the change to Sagan is trivial, but I?d rather only do something like this once. I?d also happily audit and accept pull requests on GitHub if anyone fancies writing a patch themselves. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Tue Nov 18 12:26:09 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 18 Nov 2014 12:26:09 +0100 Subject: [atlas] Ooredoo (QA) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called qa-doh-as8781 and it is hosted by Ooredoo in Doha, Qatar on behalf of RIPE NCC since they are one of our K-root hosts. This is the first anchor in Middle East. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From furry13 at gmail.com Tue Nov 18 15:50:37 2014 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 18 Nov 2014 15:50:37 +0100 Subject: [atlas] Atlas Sagan library and UDP tarceroute results: bug or feature? In-Reply-To: <546A28CB.1030208@ripe.net> References: <546A28CB.1030208@ripe.net> Message-ID: Hi Daniel, Thanks a lot for your response! On Mon, Nov 17, 2014 at 5:56 PM, Daniel Quinn wrote: > On 31/10/14 15:15, Jen Linkova wrote: > The proposal is to remove target_responded and introduce two new properties: > > A boolean named destination_ip_responded to reflect the current behaviour of > target_responded It's nice to have but IMHO it's optional as it's easy to compare destination_ip with the last responded hop ip if last_hop_responded is set to True. > A boolean named something like last_hop_responded or just target_responded > representing whether the last hop was a response at all. IMHO it would be very useful. BTW a feature request: would it be possible to have a way to distinguish between 'target did not respond/maxhops exceeded' and 'traceroute stopped because ICMP error message (but not Port Unreachable in case of UDP traceroute) received)? > > What do you (and the others on this list) think of this? Making the change > to Sagan is trivial, but I?d rather only do something like this once. > > I?d also happily audit and accept pull requests on GitHub if anyone fancies > writing a patch themselves. -- SY, Jen Linkova aka Furry From mgalante at ripe.net Tue Nov 18 16:22:18 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 18 Nov 2014 16:22:18 +0100 Subject: [atlas] LINX (UK) has joined RIPE Atlas anchors Message-ID: <1986FB45-FAF7-4EEE-A7B5-8AA747C26967@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called uk-lon-as5459 and it is hosted by LINX in London, United Kingdom on behalf of RIPE NCC since they are one of our k-root hosts and RIS Remote Route Collector locations. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mgalante at ripe.net Wed Nov 19 12:14:41 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 19 Nov 2014 12:14:41 +0100 Subject: [atlas] Go6 Institute (SI) has joined RIPE Atlas anchors Message-ID: <31BDBE3C-055A-44DA-B0B7-770467EBEF0B@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called si-lzp-as198644 and is hosted by the Go6 Institute in Skofja Loka, Slovenia, and sponsored by SIDN, Netherlands. Thank you to SIDN for sponsoring this anchor! There are more organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb at ripe.net Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From ruwaifa.anwar at gmail.com Thu Nov 20 02:43:38 2014 From: ruwaifa.anwar at gmail.com (Ruwaifa Anwar) Date: Wed, 19 Nov 2014 20:43:38 -0500 Subject: [atlas] Maximum daily spending limit reached Message-ID: I'm getting this error:- "Executing this measurement request would violate your maximum daily spending limit of 1000000.0 credits". I have double checked my request. It's expected credit consumption is way less than daily limit and I don't have any other UDM running. Is there a bug in v1 API? _______________________ Regards, Muhammad Ruwaifa Anwar -------------- next part -------------- An HTML attachment was scrubbed... URL: From furry13 at gmail.com Thu Nov 20 08:57:23 2014 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 20 Nov 2014 08:57:23 +0100 Subject: [atlas] Maximum daily spending limit reached In-Reply-To: References: Message-ID: On Thu, Nov 20, 2014 at 2:43 AM, Ruwaifa Anwar wrote: > I'm getting this error:- > "Executing this measurement request would violate your maximum daily > spending limit of 1000000.0 credits". > I have double checked my request. It's expected credit consumption is way > less than daily limit and I don't have any other UDM running. Is there a bug > in v1 API? Looks like that, I saw the same issue (reported already). Are you trying to create one-off measurement? -- SY, Jen Linkova aka Furry From alexsaroyan at gmail.com Thu Nov 20 14:11:43 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Thu, 20 Nov 2014 17:11:43 +0400 Subject: [atlas] Maximum daily spending limit reached In-Reply-To: References: Message-ID: <546DE88F.9050409@gmail.com> Furry, AFAIK that bug was reported by me and solved - seems this is something else. Regards. /Alex Saroyan On 11/20/2014 11:57 AM, Jen Linkova wrote: > On Thu, Nov 20, 2014 at 2:43 AM, Ruwaifa Anwar wrote: >> I'm getting this error:- >> "Executing this measurement request would violate your maximum daily >> spending limit of 1000000.0 credits". >> I have double checked my request. It's expected credit consumption is way >> less than daily limit and I don't have any other UDM running. Is there a bug >> in v1 API? > Looks like that, I saw the same issue (reported already). Are you > trying to create one-off measurement? > From klaus.mailinglists at pernau.at Thu Nov 20 16:32:02 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Nov 2014 16:32:02 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS Message-ID: <546E0972.4000502@pernau.at> Hi! I want to monitor an Anycasted authoritative name server: - are all nodes responding - are all nodes in routing ... So I thought about starting a long term DNS measurement with plenty of probes and NSID queried. Then, checking the results I should see every possible NSID if there are for more probes than Anycast-nodes. Does anybody have done that (or similar) already and want to share code? Can the RIPE Atlas Status Checks be used for such monitoring? Thanks Klaus From atlas at liman.net Fri Nov 21 10:32:33 2014 From: atlas at liman.net (Lars-Johan Liman) Date: Fri, 21 Nov 2014 10:32:33 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <546E0972.4000502@pernau.at> (Klaus Darilion's message of "Thu, 20 Nov 2014 16:32:02 +0100") References: <546E0972.4000502@pernau.at> Message-ID: <22ppcgrj9q.fsf@limac.netnod.se> klaus.mailinglists at pernau.at: > Hi! > I want to monitor an Anycasted authoritative name server: > ... > Does anybody have done that (or similar) already and want to share > code? There is plenty of that going on already. Please check if you can make use of someone else's measurements before deploying your own, especially if you want to monitor someone else's servers. They may already be in there somewhere and duplicating efforts is less than ... optimal. :-) Best regards, /Lars-Johan Liman Operator of anycast servers for the root, and several TLDs. :-) #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman at netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- From bortzmeyer at nic.fr Fri Nov 21 10:40:06 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 21 Nov 2014 10:40:06 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <546E0972.4000502@pernau.at> References: <546E0972.4000502@pernau.at> Message-ID: <20141121094006.GA13152@nic.fr> On Thu, Nov 20, 2014 at 04:32:02PM +0100, Klaus Darilion wrote a message of 18 lines which said: > Does anybody have done that (or similar) already and want to share code? https://labs.ripe.net/Members/stephane_bortzmeyer/the-many-instances-of-the-l-root-name-server https://labs.ripe.net/Members/stephane_bortzmeyer/using-atlas-udm-to-find-the-popular-instances-of-a-dns-anycast-name-server From klaus.mailinglists at pernau.at Fri Nov 21 13:05:24 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Fri, 21 Nov 2014 13:05:24 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <22ppcgrj9q.fsf@limac.netnod.se> References: <546E0972.4000502@pernau.at> <22ppcgrj9q.fsf@limac.netnod.se> Message-ID: <546F2A84.9060308@pernau.at> On 21.11.2014 10:32, Lars-Johan Liman wrote: > Please check if you can make > use of someone else's measurements before deploying your own How will I know if such measurements exists and how will I find these measurements? And how will I make sure that these measurements are not stopped and my monitoring wakes me at midnight? regards Klaus From dquinn at ripe.net Fri Nov 21 13:57:57 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 21 Nov 2014 13:57:57 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <546E0972.4000502@pernau.at> References: <546E0972.4000502@pernau.at> Message-ID: <546F36D5.70601@ripe.net> Unfortunately, the status checks system is currently limited to ping measurements, but we're interested in how some of you might like to see DNS support rolled in. In the interim though, you can use: * The measurement-latest API (https://atlas.ripe.net/api/v1/measurement-latest//) to fetch the most recent result at any given time * Sagan (https://github.com/RIPE-NCC/ripe.atlas.sagan) to parse the results and find what you're looking for I hope that helps :-) From bortzmeyer at nic.fr Fri Nov 21 14:44:26 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 21 Nov 2014 14:44:26 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <546F2A84.9060308@pernau.at> References: <546E0972.4000502@pernau.at> <22ppcgrj9q.fsf@limac.netnod.se> <546F2A84.9060308@pernau.at> Message-ID: <20141121134425.GA30639@nic.fr> On Fri, Nov 21, 2014 at 01:05:24PM +0100, Klaus Darilion wrote a message of 10 lines which said: > How will I know if such measurements exists As far as I know, there is no search engine for RIPE Atlas measurements ("find me all the DNS measurements against 8.8.8.8"). I've been told it is, at least partially, for privacy reasons (it would be useful for some people to learn what is monitored). From philip.homburg at ripe.net Fri Nov 21 14:56:01 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 21 Nov 2014 14:56:01 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <20141121134425.GA30639@nic.fr> References: <546E0972.4000502@pernau.at> <22ppcgrj9q.fsf@limac.netnod.se> <546F2A84.9060308@pernau.at> <20141121134425.GA30639@nic.fr> Message-ID: <546F4471.4060608@ripe.net> On 2014/11/21 14:44 , Stephane Bortzmeyer wrote: > On Fri, Nov 21, 2014 at 01:05:24PM +0100, > Klaus Darilion wrote > a message of 10 lines which said: > >> How will I know if such measurements exists > > As far as I know, there is no search engine for RIPE Atlas > measurements ("find me all the DNS measurements against > 8.8.8.8"). I've been told it is, at least partially, for privacy > reasons (it would be useful for some people to learn what is > monitored). Hi, There is in RIPEstat. See for example https://stat.ripe.net/8.8.8.8#tabId=activity Philip From dquinn at ripe.net Fri Nov 21 15:08:28 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 21 Nov 2014 15:08:28 +0100 Subject: [atlas] Using Atlas for Monitoring of Anycast DNS In-Reply-To: <20141121134425.GA30639@nic.fr> References: <546E0972.4000502@pernau.at> <22ppcgrj9q.fsf@limac.netnod.se> <546F2A84.9060308@pernau.at> <20141121134425.GA30639@nic.fr> Message-ID: <546F475C.9010907@ripe.net> The new Measurements listing has search capability: https://atlas.ripe.net/measurements/?search=8.8.8.8&kind=6%2C7 That might help. From BECHA at ripe.net Fri Nov 21 15:30:04 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 21 Nov 2014 15:30:04 +0100 Subject: [atlas] Fwd: [AFRINIC-announce] AFRINIC-RIPE Atlas Initiative In-Reply-To: <546F3F3C.6090901@afrinic.net> References: <546F3F3C.6090901@afrinic.net> Message-ID: <546F4C6C.4050009@ripe.net> FYI -- Cooperation between AfriNIC & RIPE NCC / RIPE Atlas. Vesna -------- Original Message -------- Subject: [AFRINIC-announce] AFRINIC-RIPE Atlas Initiative Date: Fri, 21 Nov 2014 17:33:48 +0400 From: AFRINIC Communication To: announce at afrinic.net Dear Members/Colleagues, Following the MoU signed with the RIPE NCC in Abidjan, AFRINIC has launched an initiative to increase the number of probes and anchors in the AFRINIC service region. The ?AFRINIC/RIPE Atlas Initiative? aims to support Internet measurements both globally and within our region. We are therefore relying on our members' support to help us build this network. We would also like take this opportunity to thank all those members who are already hosting probes and anchors and are keeping them online. How to Get Your AFRINIC/RIPE Atlas Probe ------------------------------------ For those who would like to support this initiative, AFRINIC and the RIPE NCC have implemented a new channel of distribution to make it easier for AFRINIC members to apply and receive their probe. If you would like to apply to host a probe, all you need to do is register online and make a request. After evaluation by the AFRINIC/RIPE NCC Atlas Team, probes will be shipped directly to successful applicants. Please note that this initiative is exclusively for AFRINIC members. More Information -------------- More information about the initiative and how to apply for and host a probe can be found athttp://www.afrinic.net/en/initiatives/afrinicripe-atlas If you are attending the AFRINIC-21 Meeting taking place from 22-28 November in Mauritius, you can also ask any AFRINIC staff member for more information about this initiative. Kind regards, AFRINIC Communications Team ................................... Chers membres/coll?gues, Suite au protocole d'accord sign? avec le Registre Internet Regional Europeen, RIPE NCC, ? Abidjan, AFRINIC a lanc? une initiative visant ? accro?tre le nombre de sondes Atlas dans la r?gion de service d'AFRINIC. L'initiative "AFRNIC -RIPE Atlas " vise ? soutenir les mesures de l'Internet au niveau mondial et au sein de notre r?gion. Nous comptons donc sur le soutien de nos membres pour nous aider ? construire ce r?seau. Nous profitons de l'occasion pour remercier les membres qui h?bergent d?j? des sondes tout en les gardant en ligne. Comment obtenir votre sonde Atlas. Pour ceux qui sont pr?ts ? soutenir cette initiative, AFRINIC et RIPE NCC ont mis en place une nouvelle cha?ne de distribution pour les membres d'AFRINIC qui peuvent facilement faire une application et obtenir leurs sondes. Si vous souhaitez h?berger une sonde, tout ce que vous devez faire est de vous inscrire en ligne et soumettre votre demande. Apres ?valuation par l'Equipe d'AFRINIC-RIPE Atlas, les sondes seront directement envoy?s aux candidats selectionn?s par l?Equipe du projet. Plus d'informations ...................................... Plus d'informations sur l'initiative et comment faire une application pour h?berger une sonde ? :http://www.afrinic.net/en/initiatives/afrinicripe-atlas Si vous participez ? la R?union d'AFRINIC-21, qui se tiendra du22-28 novembre ? Maurice, vous pouvez contacter le personnel d'AFRINIC pour plus d'informations sur cette initiative. L'Equipe de Communication d'AFRINIC _______________________________________________ announce mailing list announce at afrinic.net https://lists.afrinic.net/mailman/listinfo.cgi/announce From thomasholterbach at gmail.com Mon Nov 24 09:18:44 2014 From: thomasholterbach at gmail.com (Thomas Holterbach) Date: Mon, 24 Nov 2014 17:18:44 +0900 Subject: [atlas] Be careful with probe 4981 In-Reply-To: References: Message-ID: Hi, I am now going to perform some tests on the probe 503 (ASN 8365) during the next two weeks. Please note that during this period, measurements from or toward this probe might be inaccurate. Thank you for your attention, Thomas 2014-10-31 16:34 GMT+09:00 Thomas Holterbach : > Hi, > > I am going to perform some tests on our atlas probe (id 4981, ASN 3130) > during the next two or three weeks. Please note that during this period, > measurements from or toward this probe might be inaccurate. > > Thank you for your attention, > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From astracha at ripe.net Tue Nov 25 16:41:52 2014 From: astracha at ripe.net (Alastair Strachan) Date: Tue, 25 Nov 2014 16:41:52 +0100 Subject: [atlas] Wikimedia Foundation (United States) has joined RIPE Atlas anchors Message-ID: <57E5716A-B582-4CA6-8EEE-AE40E11C23EF@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-qas-as14907 and it is hosted by Wikimedia Foundation in Ashburn, United States Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Wed Nov 26 14:51:14 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 26 Nov 2014 13:51:14 +0000 Subject: [atlas] Wikimedia Foundation (United States) has joined RIPE Atlas anchors In-Reply-To: <57E5716A-B582-4CA6-8EEE-AE40E11C23EF@ripe.net> References: <57E5716A-B582-4CA6-8EEE-AE40E11C23EF@ripe.net> Message-ID: <3BB049E9-F466-463C-8C20-EA36F11C3024@mx5.org.uk> I assume we can edit the dataset output of their anchor without the edits being reverted :):( ho hum.. Colin > On 25 Nov 2014, at 15:41, Alastair Strachan wrote: > > Dear RIPE Atlas users, > > We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. > > The new anchor is called us-qas-as14907 and it is hosted by Wikimedia Foundation in Ashburn, United States > > Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. > > You can access the anchoring measurements for all anchors at: > https://atlas.ripe.net/anchors/list/ > > Learn more about RIPE Atlas anchors at: > https://atlas.ripe.net/about/anchors/ > > Thank you for participating in RIPE Atlas! > > Kind Regards, > > RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Wed Nov 26 16:49:19 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 26 Nov 2014 16:49:19 +0100 Subject: [atlas] Wikimedia Foundation (Carrollton, US) has joined RIPE Atlas anchors Message-ID: <2F74C5C8-C4AB-482F-8D50-1E9AF08CB537@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-cax-as14907 and it is hosted by Wikimedia Foundation in Carrollton, United States. Congratulations to Wikimedia Foundation for their second anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From schofield at terena.org Thu Nov 27 14:52:47 2014 From: schofield at terena.org (Brook Schofield) Date: Thu, 27 Nov 2014 14:52:47 +0100 Subject: [atlas] MAT-WG proposal for WLAN measurements on RIPE Atlas Message-ID: MAT-WG, thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69. You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40 To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points: #1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host. #2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement. For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process. #3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network. The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case. #4: The schedule for implementation will be determined by the RIPE NCC R&D team ...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community. #5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different. My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further. Thanks, -Brook -- =================================================== Brook Schofield, Project Development Officer G?ANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.g?ant.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Thu Nov 27 15:30:10 2014 From: mgalante at ripe.net (Michela Galante) Date: Thu, 27 Nov 2014 15:30:10 +0100 Subject: [atlas] MIX (IT) has joined RIPE Atlas anchors Message-ID: <87B4F3C8-87F1-424C-8223-7768FB57F8AF@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called it-mil-as16004 and it is hosted by Milan Internet eXchange (MIX) in Milan, Italy on behalf of RIPE NCC since they are one of our k-root hosts and RIS Remote Route Collector locations. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From Simon.Palmer at colegsirgar.ac.uk Thu Nov 27 15:35:01 2014 From: Simon.Palmer at colegsirgar.ac.uk (Simon Palmer) Date: Thu, 27 Nov 2014 14:35:01 +0000 Subject: [atlas] MAT-WG proposal for WLAN measurements on RIPE Atlas In-Reply-To: References: Message-ID: <5477369502000001000503A2@gwroute.colegsirgar.ac.uk> Hi Brook, This looks like a great. The certificate/port checks/NAT checks would be very useful. Other things that could probably be reported easily for diagnostics are 2.4Ghz vs 5Ghz, link speed, signal. I read https://ripe69.ripe.net/archives/steno/40/ - we do drop our NREN test user into a blackhole vlan, but would change that for this test! Cheers, >>> Brook Schofield 27/11/2014 13:52 >>> MAT-WG, thankyou for giving me the opportunity to present on "The Value of WLAN Measurements for the R&E Community" at the Measurement and Tools Working Group at RIPE69. You can find my presentation and stenography logs at: https://ripe69.ripe.net/presentations/91-eduroam-and-Atlas-RIPE69.pdf https://ripe69.ripe.net/archives/steno/40 To progress this work within the RIPE NCC Atlas development team I'd like your input into the following five (5) points: #1: For "opt-in" WLAN measurements to be enabled on RIPE Atlas As a point of clarification (and reiterated by Daniel Karrenberg) the intention is that ALL v3 probes will be capable of WLAN measurements - but measurements will ONLY be turned on by a probe host. #2: WLAN measurements will support associating to an "open" or 802.1X protected network for the purposes of performing a measurement As an active monitoring network the Atlas probes WILL NOT scan and report on all/available SSIDs. It will ONLY associate with EXPLICITLY defined SSIDs listed in the measurement. For eduroam quality purposes the success/failure of an 802.1X associations is initially the most interesting part of the measurement in determining whether sites are correctly deploying this service. There will be results related to the authentication process. #3: Any measurements performed over the wireless interface are aligned with a request to associate/authenticate to a particular network. The wireless interface will be connected only for particular tests bundled with the association to an SSID. All other tests will be performed via the wired interface as is currently the case. #4: The schedule for implementation will be determined by the RIPE NCC R&D team ...but hopefully your support for this work will allow them to prioritise this work while not jeopardising the other commitments the team has made to the community. #5: This proposal is inline with your understanding of "WiFi measurements" on the Atlas roadmap I'd be particularly interested in your feedback on whether you thought that the WiFi Measurements listed in the http://roadmap.ripe.net/ripe-atlas/ would accomplish the above or something completely different. My feeling from the room was that the above was largely accepted. I'd appreciate those that voiced their support to also do this on the mailing list again. If there's any confusion I'm willing to clarify further. Thanks, -Brook -- =================================================== Brook Schofield, Project Development Officer G?ANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 ( tel:%2B31%2020%20530%204488) Fax +31 20 530 4499 ( tel:%2B31%2020%20530%204499) Mob +31 65 155 3991 www.g?ant.org ( http://www.xn--gant-bpa.org) Mae'r e-bost hwn ac unrhyw ffeiliau atodedig yn gyfrinachol ac at sylw'r unigolyn neu'r sefydliad a enwir uchod. Bydd unrhyw farn neu sylwadau a fynegir yn perthyn i'r awdur yn unig ac ni chynrychiolant o anghenraid farn Coleg Sir G?r. Os ydych chi wedi derbyn yr e-bost hwn ar gam, rhowch sylw i'r gweinyddwr ar y cyfeiriad canlynol: postmaster at colegsirgar.ac.uk Cysidrwch yr amgylchedd - a oes wir angen argraffu'r ebost hwn? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Coleg Sir G?r. If you have received this email in error please notify the admin istrator on the following address: postmaster at colegsirgar.ac.uk Please consider the environment - do you really need to print this email?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Thu Nov 27 16:04:07 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 27 Nov 2014 16:04:07 +0100 Subject: [atlas] MAT-WG proposal for WLAN measurements on RIPE Atlas In-Reply-To: <5477369502000001000503A2@gwroute.colegsirgar.ac.uk> References: <5477369502000001000503A2@gwroute.colegsirgar.ac.uk> Message-ID: <54773D67.5000606@ripe.net> Hi Simon, Atlas probes do not support 5Ghz. Victor Naumov R&D RIPE NCC On 11/27/14, 3:35 PM, Simon Palmer wrote: > Other things that could probably be reported easily for diagnostics > are 2.4Ghz vs 5Ghz, link speed, signal. From shahin at gharghi.ir Wed Nov 26 15:17:52 2014 From: shahin at gharghi.ir (Shahin Gharghi) Date: Wed, 26 Nov 2014 17:47:52 +0330 Subject: [atlas] Credits Message-ID: Hi The RIPE Atlas hosts earn credit for the time their probes remain connected. I think it could be better to receive additional credit whenever someone uses that probe to make measurement. And if crowded probes be more expensive, we can distribute the load between same probes better. -- Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Fri Nov 28 13:11:31 2014 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 28 Nov 2014 07:11:31 -0500 Subject: [atlas] Credits In-Reply-To: References: Message-ID: <28FF9195-3DC2-45BF-8D01-EAAA33232DBF@puck.nether.net> Do you need credits? Happy to share some that I have. Jared Mauch > On Nov 26, 2014, at 9:17 AM, Shahin Gharghi wrote: > > Hi > The RIPE Atlas hosts earn credit for the time their probes remain connected. I think it could be better to receive additional credit whenever someone uses that probe to make measurement. > And if crowded probes be more expensive, we can distribute the load between same probes better. > > -- > Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From schofield at terena.org Fri Nov 28 16:19:29 2014 From: schofield at terena.org (Brook Schofield) Date: Fri, 28 Nov 2014 16:19:29 +0100 Subject: [atlas] MAT-WG proposal for WLAN measurements on RIPE Atlas In-Reply-To: <54773D67.5000606@ripe.net> References: <5477369502000001000503A2@gwroute.colegsirgar.ac.uk> <54773D67.5000606@ripe.net> Message-ID: Actually it doesn't support 2.4GHz either :-) but at least the v3 hardware can - if the community agree that #1 in my proposal is a a good idea. I'm sure a future hardware platform for RIPE Atlas (v4, v5) will support 5GHz while mainting the competitve pricing of the current hardware. -Brook On 27 November 2014 at 16:04, Viktor Naumov wrote: > Hi Simon, > > Atlas probes do not support 5Ghz. > > Victor Naumov > R&D RIPE NCC > > > On 11/27/14, 3:35 PM, Simon Palmer wrote: > >> Other things that could probably be reported easily for diagnostics are >> 2.4Ghz vs 5Ghz, link speed, signal. >> > > -- =================================================== Brook Schofield, Project Development Officer G?ANT Association, Singel 468 D, 1017 AW Amsterdam, The Netherlands Tel +31 20 530 4488 Fax +31 20 530 4499 Mob +31 65 155 3991 www.g?ant.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From shahin at gharghi.ir Wed Nov 26 15:56:01 2014 From: shahin at gharghi.ir (Shahin Gharghi) Date: Wed, 26 Nov 2014 18:26:01 +0330 Subject: [atlas] Software Probs Message-ID: Dear RIPE Atlas team I want to ask why don't you make software probes? RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make RIPE Atlas VMWare image or an RPM,deb package and even windows service. So people can install them on their servers. The other way to save probes is making probes multi-home. For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes. -- Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumalop at afri-com.net Fri Nov 28 18:04:39 2014 From: kumalop at afri-com.net (Promise Kumalo) Date: Fri, 28 Nov 2014 19:04:39 +0200 Subject: [atlas] Software Probs In-Reply-To: References: Message-ID: <5478AB27.3080406@afri-com.net> valid point On 26/11/2014 16:56, Shahin Gharghi wrote: > Dear RIPE Atlas team > > I want to ask why don't you make software probes? > RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily > make RIPE Atlas VMWare image or an RPM,deb package and even windows > service. So people can install them on their servers. > > The other way to save probes is making probes multi-home. > For example I have 4 probes in one place to monitor 4 different IP > prefixes and paths. I know because of the hardware limits we can't use > sub-interfaces but we can set 4 IP addresses manually and add 4 any > route by the source, then we can save 3 other probes. > > -- > Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Fri Nov 28 18:27:44 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 28 Nov 2014 18:27:44 +0100 Subject: [atlas] Software Probs In-Reply-To: References: Message-ID: <5478B090.70209@ripe.net> Dear Shahin, On 26-nov.-14 15:56, Shahin Gharghi wrote: > Dear RIPE Atlas team > > I want to ask why don't you make software probes? we regularly get these questions, and we have documented the reply here: https://atlas.ripe.net/about/faq/#why-did-you-choose-a-hardware-solution-instead-of-software There are other projects that do measurements using virtual machines or SW applications, that might be more suitable for your needs, for example NLNOG RING: https://ring.nlnog.net/ We cooperate with them on several levels, but out goals are slightly different. For example, using RIPE Atlas you can target RING nodes: https://atlas.ripe.net/targets/ringnodes/map/ > RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily > make RIPE Atlas VMWare image or an RPM,deb package and even windows > service. So people can install them on their servers. > > The other way to save probes is making probes multi-home. > > For example I have 4 probes in one place to monitor 4 different IP > prefixes and paths. I know because of the hardware limits we can't use > sub-interfaces but we can set 4 IP addresses manually and add 4 any > route by the source, then we can save 3 other probes. > Now that's an interesting idea, and I can say that we'll take it into consideration -- but you have already mentioned HW limits yourself. Please take a look at our roadmap, where we document major feature requests. SW probe is also there, as "requested", along with the link to the explanation why we are not going to go for that solution now: http://roadmap.ripe.net/ripe-atlas/ Regards, Vesna Manojlovic Community Builder for Measurements Tools From nicolas at ncartron.org Fri Nov 28 18:24:41 2014 From: nicolas at ncartron.org (nicolas at ncartron.org) Date: Fri, 28 Nov 2014 17:24:41 +0000 Subject: [atlas] Software Probs In-Reply-To: References: Message-ID: On Wed Nov 26 15:56:01 2014 GMT+0100, Shahin Gharghi wrote: > Dear RIPE Atlas team > > I want to ask why don't you make software probes? > RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make > RIPE Atlas VMWare image or an RPM,deb package and even windows service. So > people can install them on their servers. I guess a "plug and play" approach. Also if RIPE NCC does VMware images, why not KVM or Hyper-V? Tough to keep up... -- Sent from my Jolla From philip.homburg at ripe.net Fri Nov 28 18:52:08 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 28 Nov 2014 18:52:08 +0100 Subject: [atlas] Software Probs In-Reply-To: References: Message-ID: <5478B648.8080709@ripe.net> Hi Shahin, On 2014/11/26 15:56 , Shahin Gharghi wrote: > The other way to save probes is making probes multi-home. > For example I have 4 probes in one place to monitor 4 different IP > prefixes and paths. I know because of the hardware limits we can't use > sub-interfaces but we can set 4 IP addresses manually and add 4 any > route by the source, then we can save 3 other probes. One thing to keep in mind is that there are very good reasons to try to keep probes as simple as possible. Even if that means installing 4 probes in one location. Extra complexity translates into extra testing effort and more bugs. What is gained by using the hardware more efficiently can be lost easily in more engineering effort. At this moment, making a probe multi-homed would be a significant engineering effort because just about all code implicitly assumes that every probe has exactly one interface. (I assume that from a hardware point of view, VLAN tagging would allow a probe to be connect to different ethernets) Philip From the.lists at mgm51.com Sun Nov 30 04:19:28 2014 From: the.lists at mgm51.com (Mike.) Date: Sat, 29 Nov 2014 22:19:28 -0500 Subject: [atlas] Many thanks :) Message-ID: <201411292219280835.008F4CEA@smtp.24cl.home> A short note to say 'thank-you' for the ability to configure the origination of an email message when the probe under my supervision has been offline for a short while. I was doing some work on my firewall today, and I neglected to re-plug the probe back into the USB port for power. The email informed me of my transgression. :) Mike. From shahin at gharghi.ir Sat Nov 29 08:34:16 2014 From: shahin at gharghi.ir (Shahin Gharghi) Date: Sat, 29 Nov 2014 11:04:16 +0330 Subject: [atlas] Software Probs In-Reply-To: <5478B648.8080709@ripe.net> References: <5478B648.8080709@ripe.net> Message-ID: Dear Vesna Thank you for your explanation and Thank others for their reply. I think only this reason prevents you to make a software probe : - It is easier to tamper with the results. This is also why we chose not to release a software version in tandem with the hardware solution ?.? And I think the hardware problem could be solved by changing the LAN chipset ( Maybe TPLink do this for you). On Fri, Nov 28, 2014 at 9:22 PM, Philip Homburg wrote: > Hi Shahin, > > On 2014/11/26 15:56 , Shahin Gharghi wrote: > > The other way to save probes is making probes multi-home. > > For example I have 4 probes in one place to monitor 4 different IP > > prefixes and paths. I know because of the hardware limits we can't use > > sub-interfaces but we can set 4 IP addresses manually and add 4 any > > route by the source, then we can save 3 other probes. > > One thing to keep in mind is that there are very good reasons to try to > keep probes as simple as possible. Even if that means installing 4 > probes in one location. > > Extra complexity translates into extra testing effort and more bugs. > What is gained by using the hardware more efficiently can be lost easily > in more engineering effort. > > At this moment, making a probe multi-homed would be a significant > engineering effort because just about all code implicitly assumes that > every probe has exactly one interface. > > (I assume that from a hardware point of view, VLAN tagging would allow a > probe to be connect to different ethernets) > > Philip > -- Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From shahin at gharghi.ir Sat Nov 29 08:37:21 2014 From: shahin at gharghi.ir (Shahin Gharghi) Date: Sat, 29 Nov 2014 11:07:21 +0330 Subject: [atlas] Credits In-Reply-To: <28FF9195-3DC2-45BF-8D01-EAAA33232DBF@puck.nether.net> References: <28FF9195-3DC2-45BF-8D01-EAAA33232DBF@puck.nether.net> Message-ID: Thank you Jared I actually have 10 Million credits. That was just a suggestion. On Fri, Nov 28, 2014 at 3:41 PM, Jared Mauch wrote: > Do you need credits? Happy to share some that I have. > > Jared Mauch > > On Nov 26, 2014, at 9:17 AM, Shahin Gharghi wrote: > > Hi > The RIPE Atlas hosts earn credit for the time their probes remain > connected. I think it could be better to receive additional credit whenever > someone uses that probe to make measurement. > And if crowded probes be more expensive, we can distribute the load > between same probes better. > > -- > Shahin Gharghi > > -- Shahin Gharghi -------------- next part -------------- An HTML attachment was scrubbed... URL: