- ripe-atlas - mailman.ripe.net

Mistakenly sent "please register your probe" emails
by Robert Kisteleki 05 Mar '15

05 Mar '15

Dear RIPE Atlas users, As part of our regular development schedule, the development team rolled out a new version of the infrastructure components yesterday. As a side-effect, due to a mistake on our end, some users received emails urging them to register their probe(s), even though this has already been done. If you got such a mail although you've done your part, then please ignore this mail. Our apologies for the confusion. Regards, Robert Kisteleki

1 0

University of Twente (Enschede, The Netherlands) has joined RIPE Atlas Anchors
by Alastair Strachan 27 Feb '15

27 Feb '15

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 nl-ens-as1133 and it is hosted by University of Twente in Enschede, The Netherlands 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

some probes not returning NSID
by Paul Vlaar 26 Feb '15

26 Feb '15

Hi all, it appears that some probes never return NSID, when requested, while others do, for the same query. For example: https://atlas.ripe.net/measurements/1875836/#!general As you can see NSID is set to True. These are the raw results from the two probes, for a one-off DNS UDM: results = { u'6012': [{u'lts': 230, u'proto': u'UDP', u'from': u'193.0.19.108', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384037, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 6012, u'result': {u'abuf': u'OQGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACUAAwAhbnMwMDBiLmFwcDcubnJ0MS5hZmlsaWFzLW5zdC5pbmZv', u'rt': 312.971, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 900, u'SERIAL': 2011382635, u'TYPE': u'SOA'}], u'ID': 14593, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 132}, u'src_addr': u'193.0.19.108', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}], u'10039': [{u'lts': 166, u'proto': u'UDP', u'from': u'96.237.232.254', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384040, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 10039, u'result': {u'abuf': u'qxGAgAABAAEAAAABA29yZwAABgABwAwABgABAAAB3QAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2UAAAcIAAADhAAJOoAAAVGAAAApD6AAAAAAAAA=', u'rt': 8.299, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 477, u'SERIAL': 2011382629, u'TYPE': u'SOA'}], u'ID': 43793, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 95}, u'src_addr': u'192.168.13.40', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}] } Sagan tells me, for probe 6012, responses[0].abuf.raw_data is: {'HEADER': {'AA': True, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': False, 'Z': 0, 'ID': 14593}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 900, 'Serial': 2011382635, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [{'OptionCode': 3, 'OptionName': 'NSID', 'NSID': u'ns000b.app7.nrt1.afilias-nst.info', 'OptionLength': 33}], 'UDPsize': 4096, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is present. And for 10039: {'HEADER': {'AA': False, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': True, 'Z': 0, 'ID': 43793}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 477, 'Serial': 2011382629, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [], 'UDPsize': 4000, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is missing. Why is this? I've tried increasing the payload size, this makes no difference. I get the same when I try for SOA . @ k.root-servers.net: Compare these outcomes: https://atlas.ripe.net/measurements/1875933/ https://atlas.ripe.net/measurements/1875926/ It appears to me that probe 10039 (or its network) has a problem of sorts, causing this. It would be great if faulty probes can be weeded out, if this is really the case. BTW, I am always getting "null" on the NSID field in the web interface, regardless of whether it lives in abuf, or not. This seems to be a bug. ~paul

9 15

[ietf-secretariat@ietf.org: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols]
by Stephane Bortzmeyer 26 Feb '15

26 Feb '15

It could be interesting to use Atlas probes for such measurements, no?

2 1

Re: [atlas] Fwd: Re: Proble locations (Changed because of Geo-IP)
by Chris Amin 25 Feb '15

25 Feb '15

Dear Martin, I'm sorry for this, we recently made a change which keeps the location of those probes which are geolocated (i.e. *without* a manually set address) up to date. Previously such probes were geolocated once, and never again. It was never the intention to overwrite manually given locations. Unfortunately, it seems that a number of probes were erroneously marked as being automatically geolocated when in fact their owners had carefully provided a location. We are now looking at our logs to see how many probes might have been affected by this, and whether we can automatically revert the location in those cases. As for your point about not being able to enter the location, there is a text box above the map popup which should allow you to enter a textual address. If this isn't working for you, please let me know. Apologies once again. Kind regards, Chris Amin RIPE NCC On Wed, 25 Feb 2015 01:10:30 -0800 (PST), Martin Winter wrote: > I have actually the address in it. > The earlier webpage had a way to enter Lat/Lon for probes (which I can't > find anymore). > > I think a simple Geo-Lokup based on addresses in description would have > done a much better job. > But a field to enter lat/lon in it and take this as a preference (if > entered) without going to overwrite it would be a good start. > > I mainly worry on whatever happend there in this process may have > misplaced a lot of probes to the wrong location. > Anyone else noticed that their probe moved to a new (wrong) location? > > - Martin > > > On Wed, 25 Feb 2015, Grewal, Jas wrote: > >> Agreed, how about including this critical information in the >> description field to get around this, perhaps? >> >> -----Original Message----- >> From: ripe-atlas [mailto:ripe-atlas-bounces@ripe.net] On Behalf Of >> Martin Winter >> Sent: 25 February 2015 07:29 >> To: ripe-atlas(a)ripe.net >> Subject: [atlas] Proble locations (Changed because of Geo-IP) >> >> So I've noticed that (at least some) probes got the location >> automatically updated based on Geo IP. >> However, this is frequently fundamentially broken. One of my probe >> moved from San Jose, CA to somewhere in the middle of Texas. (Broken >> Geo-IP location for AT&T DSL users). >> (The example I talk about is proble #10770) >> >> Kind of sad... not sure how many had this happening. Specially as I >> took care to put the exact lat/lon in the User interface in the past. >> Now I can only reposition it by dragging on a map - and that seems to >> be broken as well (at least it fails to save when I try to correct >> this probes location on Chrome) >> >> I wonder how many and why there was a decision to change the location. >> I think the location were much better before they got force-changed. >> >> - Martin Winter >> >> >> >> > > > > >

2 1

FastVPS Eesti OU (Jõhvi, Estonia) has joined RIPE Atlas Anchors
by Alastair Strachan 25 Feb '15

25 Feb '15

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 ee-jvi-as198068 and it is hosted by FastVPS Eesti OU in Jõhvi, Estonia. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

Delta Softmedia Ltd (Sofia, Bulgaria) has joined RIPE Atlas Anchors
by Alastair Strachan 25 Feb '15

25 Feb '15

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 bg-sof-as197216 and it is hosted by Delta Softmedia Ltd in Sofia, Bulgaria. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

Proble locations (Changed because of Geo-IP)
by Martin Winter 25 Feb '15

25 Feb '15

So I've noticed that (at least some) probes got the location automatically updated based on Geo IP. However, this is frequently fundamentially broken. One of my probe moved from San Jose, CA to somewhere in the middle of Texas. (Broken Geo-IP location for AT&T DSL users). (The example I talk about is proble #10770) Kind of sad... not sure how many had this happening. Specially as I took care to put the exact lat/lon in the User interface in the past. Now I can only reposition it by dragging on a map - and that seems to be broken as well (at least it fails to save when I try to correct this probes location on Chrome) I wonder how many and why there was a decision to change the location. I think the location were much better before they got force-changed. - Martin Winter

2 2

New on RIPE Labs: Stopping Support for Internet Explorer 8 on Windows XP in RIPE Atlas and RIPEstat
by Mirjam Kuehne 24 Feb '15

24 Feb '15

Dear colleagues, Microsoft ended support for Windows XP as of April 2014. We're about to change RIPE Atlas and RIPEstat to stop support for Internet Explorer 8 running on these systems. Please find some more information on RIPE Labs: https://labs.ripe.net/Members/kistel/stopping-support-for-internet-explorer… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Brno University of Technology (CZ) has joined RIPE Atlas anchors
by Vesna Manojlovic 20 Feb '15

20 Feb '15

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 cz-brq-as197451 and is hosted by Brno University of Technology in Czech Republic. 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, Vesna Manojlovic Measurements Community Building Team RIPE NCC

1 0

Sagan: 'Response' object has no attribute 'edns0'
by Paul Vlaar 19 Feb '15

19 Feb '15

Hi all, I'm trying to do some basic DNS UDM result parsing using Sagan. I'd like to have an easy way to extract the NSID. I followed the instruction found here: https://www.ripe.net/ripe/mail/archives/ripe-atlas/2014-May/001475.html 'from ripe.atlas.sagan import Result result = Result("your-JSON-result-blob-here") print(result.responses[0].edns0.options[0].nsid)' That didn't work, as I get: AttributeError: 'Result' object has no attribute 'responses' So I figured I need to use a DnsResult, instead. I then have the following Python code: from ripe.atlas.sagan import DnsResult import json url = "https://atlas.ripe.net/api/v1/measurement-latest/1873691/" results = json.load(urllib.urlopen(url)) for probe in results: sagan_result = DnsResult(results[probe][0]) print(sagan_result.responses[0].edns0.options[0].nsid) This gives me: print(sagan_result.responses[0].edns0.options[0].nsid) AttributeError: 'Response' object has no attribute 'edns0' After some digging through the Sagan documentation, I found out that the way to do this should be: print(sagan_result.responses[0].abuf.edns0.options[0].nsid) This might be of help to others. ~paul

1 0

problems creating measurements with old web interface
by Klaus Darilion 13 Feb '15

13 Feb '15

Hi! Today I created some DNS tests with the old web interface. The creation process was fine, but the measurements did not work. (my target was ignored and "use probe's resolver" was automatically enabled). See UDMs: 1841832, 1841839, 1841840 btw: I can not stop 1841839 and 1841840 via the new web interface The DNS measurements only work if I create them via the new web interface. regards Klaus PS: IMO the new web interface is not very user friendly when choosing the probes - eg I failed to select 100 probes word wide (how to do this in the map)? It would be nice to have a textual alternative as my browser gets incredibly slow when showing all the probes on the map.

2 3

Larsen Data ApS (Ballerup, Denmark ) has joined RIPE Atlas Anchors
by Alastair Strachan 12 Feb '15

12 Feb '15

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 dk-blp-as197495 and it is hosted by Larsen Data ApS based in Ballerup, Denmark. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

Globalways AC (Frankfurt, Germany ) has joined RIPE Atlas Anchors
by Alastair Strachan 12 Feb '15

12 Feb '15

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 de-fra-as48918 and it is hosted by Globalways AC based in Frankfurt, Germany. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

Globalways AC (Stuttgart, Germany ) has joined RIPE Atlas Anchors
by Alastair Strachan 12 Feb '15

12 Feb '15

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 de-str-as48918 and it is hosted by Globalways AC based in Stuttgart, Germany. 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

MacOSX: probe add problems (create measurements)
by Hendrik Visage 12 Feb '15

12 Feb '15

Goodday, I'm trying to add some new measurements, but the probe selection's "+New Set - Manual" and "+Reuse a set from an old Measurement" both just flash the screen, looks like it opens a drop down windows, and closes it before I could even blink my eyes. This was tested on the Firefox 35.0.1 as well as on Safari 7.0.3 on MacOSX 10.9.3. Hendrik

2 1

Fwd: SEE4/RIPE NCC Regional Meeting: Registration Open!
by Vesna Manojlovic 09 Feb '15

09 Feb '15

Dear RIPE Atlas users, do you want to share your experiences with using RIPE Atlas with the community on "Balkans"? Please submit your talks - and see you there! Regards, Vesna -------- Forwarded Message -------- Subject: SEE 4/RIPE NCC Regional Meeting: Registration Open! Date: Mon, 26 Jan 2015 11:21:05 +0100 From: SEE <seeurope(a)ripe.net> To: ripe-list(a)ripe.net Dear colleagues, The fourth RIPE NCC Regional Meeting/South East Europe Meeting (SEE 4) takes places in Belgrade at the Metropol Palace Hotel on 21-22 April 2015. Join us there! The SEE 4/RIPE NCC Regional Meeting is open to everyone and attendance is free of charge. You can register for this meeting at: http://www.ripe.net/see-4/registration This meeting will build on the success of past meetings, which took place in Dubrovnik, Skopje and Sofia. These meetings demonstrated how vibrant the Internet community in the region is, as well as the knowledge-sharing and network-building benefits to be gained from meeting as a community. The meeting will cover a wide range of topics, including: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Efforts to establish IXPs in the region - Reports from existing IXPs - Regional success stories - Much, much more! Do you have expertise on some of these topics? An interesting case to share with your peers? Then please submit a presentation proposal here: https://www.ripe.net/ripe/meetings/regional-meetings/see-4/cfp Further information about the meeting can be found at: http://www.ripe.net/see4 See you there! Kind regards, Gergana -- Gergana Petrova Conference Coordinator RIPE Network Coordination Centre Singel 258, 1016 AB Amsterdam, The Netherlands T: +31 20 535 4444 www.ripe.net

1 0

Bug? RIPE Atlas interface mixing up legacy IP addresses
by Dan Luedtke 06 Feb '15

06 Feb '15

Hi all, I encountered some odd behaviour today using the Atlas web interface. It mixed up the octets of a legacy IP address in a funny way. Is this a bug? The corresponding probe seems to be down now /0\ I made a screen cap to document it. It was reproducible, but I am not sure if I broke it or if it is a general bug. —> http://youtu.be/Bhnyd9ogyNs Cheers Dan

2 2

Web Werks (IN) has joined RIPE Atlas anchors
by Michela Galante 02 Feb '15

02 Feb '15

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 in-bom-as33480 and it is hosted by Web Werks in Mumbai, India, and sponsored by APNIC. 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 atlas(a)ripe.net

2 1

Glitch in measurements today?
by Stephane Bortzmeyer 31 Jan '15

31 Jan '15

Many: {u'id': 7, u'name': u'Failed'} when querying measurements. It seems OK, now.

1 0

Implementing new RIPE Atlas Service Terms and Conditions
by Vesna Manojlovic 30 Jan '15

30 Jan '15

Dear colleagues, As agreed on the MAT-WG mailing list, we are in the process of implementing the new RIPE Atlas Service Terms and Conditions that clearly state the role and responsibilities for the RIPE NCC, RIPE Atlas hosts and users: https://atlas.ripe.net/legal/terms-conditions/ This is the implementation plan: - End of January, existing probe hosts will be notified by email about the upcoming transition to the new terms and conditions. - From next week (during February), existing users and probe hosts will be presented with a banner when they log in to the RIPE Atlas website, to inform them of the upcoming transition. - As of 2 March 2015, the new RIPE Atlas Service Terms and Conditions will come into effect; new probe hosts will be asked to agree to the new terms and conditions when applying for a probe; all existing probe hosts will be subject to the new terms and conditions. Thank you for your feedback and for helping us to refine these new terms. Regards, Vesna Manojlovic Measurements Community Building RIPE NCC

1 1

Hitech Service LLC (Kiev, Ukraine) has joined RIPE Atlas Anchors
by Alastair Strachan 27 Jan '15

27 Jan '15

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 ua-iev-as29632 and it is hosted by Hitech Service LLC in Kiev, Ukraine). 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

VNET a.s. (Bratislava, Slovakia) has joined RIPE Atlas Anchors
by Alastair Strachan 23 Jan '15

23 Jan '15

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-as29405 and it is hosted by VNET a.s. in Bratislav, 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 configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team

1 0

Proposal for public HTTP measurements
by Robert Kisteleki 22 Jan '15

22 Jan '15

Dear RIPE Atlas users, The topic of publicly available HTTP measurements in RIPE Atlas comes up from time to time. There were a number of discussions about pros and cons for this feature over the years (including exposing probe hosts to unnecessary risks of other users "measuring" just about any kind of HTTP content out there), with no firm outcome. While we understand that this feature would come handy for some of our users, it does not benefit everyone. Therefore our proposal is the following: 1. We'll enable HTTP measurements to be performed by all atlas users, from any probes. 2. The targets of such measurements can only be RIPE Atlas anchors (these already run HTTP servers, see https://atlas.ripe.net/docs/anchors/) 3. Parameters like costs, minimum frequency, maximum number of probes involved, etc. will be set by the development team, just as with the other measurements. 4. The RIPE NCC will still be able to support other, vetted HTTP measurements as long as it benefits the community, as well as other HTTP measurements that we deem operationally useful. These will be evaluated on a case by case basis. Please speak up at the MAT working group list (mat-wg(a)ripe.net) if you support / don't support this proposal, of if you have any other opinion about it. Regards, Robert Kisteleki RIPE NCC R&D manager, for the RIPE Atlas team

10 15

Re: [atlas] problems creating measurements with old web interface
by Massimo Candela 21 Jan '15

21 Jan '15

Hi, Thanks for the feedback! > > Subject: [atlas] problems creating measurements with old web interface > Date: Wed, 21 Jan 2015 13:49:48 +0100 > From: Klaus Darilion <klaus.mailinglists(a)pernau.at> > To: ripe-atlas(a)ripe.net > > Hi! > > Today I created some DNS tests with the old web interface. The creation > process was fine, but the measurements did not work. (my target was > ignored and "use probe's resolver" was automatically enabled). > See UDMs: 1841832, 1841839, 1841840 > > btw: I can not stop 1841839 and 1841840 via the new web interface > > > The DNS measurements only work if I create them via the new web interface. > > > regards > Klaus > > PS: IMO the new web interface is not very user friendly when choosing > the probes - eg I failed to select 100 probes word wide (how to do this > in the map)? You can do it by searching for “worldwide” (there is autosuggestion) and the widget will ask the number of probes and the tags you want to use. The number of probes is suggested and bounded according to the maximum number of probes selectable for the measurement. The idea is that whatever you write in the text field, it will try to help/guide you creating the valid (and, if needed, complex) selection you were looking for. E.g. you can do a combination by searching for “Canada ipv6” to select all the ipv6 probes in Canada Of course it can be improved, so let us know if you have other feedback! Best regards, Massimo > It would be nice to have a textual alternative as my > browser gets incredibly slow when showing all the probes on the map. > > > >

1 0