- ripe-atlas - mailman.ripe.net

BGP hijacking
by Lukasz Trabinski 20 Dec '13

20 Dec '13

Hi I know that is not related with RIPE atlas, but maybe do know where to report in RIPE BGP hijacking topic? >From today BGP table: 46.0.0.0/8 xx 33 6939 5541 I 77.0.0.0/8 xxx 33 6939 5541 I 89.0.0.0/8 xxx 33 6939 5541 I 91.0.0.0/8 xxx 33 6939 5541 I 94.0.0.0/8 xxx 33 6939 5541 I 95.0.0.0/8 xxx 33 6939 5541 I

4 4

SOX (RS) has joined RIPE Atlas anchors
by Michela Galante 20 Dec '13

20 Dec '13

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 rs-beg-as13004 and is hosted by SOX (Serbian Open eXchange) in Belgrade, Serbia. 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(a)ripe.net

1 0

DANTE (UK) has joined RIPE Atlas anchors
by Michela Galante 19 Dec '13

19 Dec '13

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-lcy-as20965 and is hosted by DANTE in London, United Kingdom. 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(a)ripe.net

1 0

ATE (FR) has joined RIPE Atlas anchors
by Michela Galante 17 Dec '13

17 Dec '13

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 fr-zdb-as35625 and is hosted by ATE in Sainghin en Mélantois, France. 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(a)ripe.net

1 0

Emergency RIPE Atlas firmware upgrade
by Robert Kisteleki 17 Dec '13

17 Dec '13

Dear RIPE Atlas users, We want to let you know about a recent issue in the RIPE Atlas system involving an open port on the latest generation (v3) probes. Due to an issue with the latest firmware release, a subset of the v3 probes were listening to incoming connections on an open port that should not have been left open. As a secondary measure, however, access to this port required credentials only available to the RIPE Atlas probe developers. It therefore never presented open access to the probes. This port (SSH) is used for development purposes in our internal development environment. We upgraded the v3 probes to a new, corrected firmware version, and improved the checks in our firmware release process. We would like to thank ZeelandNet for reporting the issue to us. We want to assure you that the security of the RIPE Atlas system is important to us. We are continually improving the controlling infrastructure as well as the probes themselves in order to prevent vulnerabilities. We apologise for this issue and want to stress that no probes were actually affected in any way. You can learn more about the security of the RIPE Atlas system on our dedicated security page at: https://atlas.ripe.net/docs/security/ Thank you for your continuing support of RIPE Atlas. Regards, Robert Kisteleki RIPE NCC

10 17

IPv6 Gateway Undetermined/Unknown
by Christopher Werny 17 Dec '13

17 Dec '13

Hi Everybody, we received our probe a couple of days ago and after successful "deployment" (with static configuration), I noticed that the Configuration pane states that the IPv6 gateway is in the state "Undetermined/Unknown". It is correctly configured and IPv6 measurements are working fine. I couldn't find anything related to my "observation", hence why I am asking here. I just want to make sure I did everything right and whether this might be a known bug or limitation? Thanks for your time. Cheers, Christopher

2 1

Enjoy the holiday season with photos of RIPE Atlas probes
by Vesna Manojlovic 13 Dec '13

13 Dec '13

Dear colleagues, we have uploaded lots of pretty photos to the Community page: https://atlas.ripe.net/get-involved/community/#!tab-actionshots I am attaching the screenshot and one, most colorful photo. Please upload your own photos, and enjoy the holiday season. Share and Enjoy :) Vesna

1 0

Re: [atlas] Measurements at an interval
by warwick 13 Dec '13

13 Dec '13

Hi Daniel, I sent an email (included below.) outlining a measurement with a specific interval done through the API and listed the response, please look at the email below. As for the Web UI measurement here is an example: /{u'result': u'/api/v1/measurement/1044471/result/', u'status': {u'id': 4, u'name': u'Stopped'}, u'msm_id': 1044471, u'interval': 1200, u'description': u'', u'participant_count': 50, u'can_visualise': False, u'resolve_on_probe': False, u'start_time': 1386161734, u'af': 6, u'creation_time': 1386161734, u'is_oneoff': False, u'stop_time': 1386165633, u'all_scheduling_requests_fulfilled': True, u'resolved_ips': [u'2001:7b8:40:1:d0e1:0:0:1'], u'dst_asn': u'12859', u'query': {u'type': u'AAAA', u'class': u'IN', u'value': u'nlnetlabs.nl.'}, u'is_public': True, u'type': {u'id': 7, u'name': u'dns'}, u'dst_addr': u'2001:7b8:40:1:d0e1:0:0:1', u'dst_name': u'2001:7b8:40:1:d0e1::1'}// / Robert Kisteleki suggested I send it through to atlas(a)ripe.net which I did and it has been listed as: [ripe.net #1113749] I received a response from Robert Kisteleki (which is the very last email included below), he said it might be a week or later until this gets investigated so he was right on the money :-) . Thank you for your response and we hope to see this bug(or whatever it is) get squashed :D P.S. If you could, please include Willem Toorop(Willem(a)nlnetlabs.nl) in the response as he was the one to mention this limitation to me and the one who suggested I email about this. He also sent an email outlining this issue but heard no response so I'm sure he would like to hear when a resolution to this limitation/bug/whatever has been found. P.P.S. At the bottom of the first included email is our work around which is get the probes specific to our needs (ipv6/4 etc..) and the chunk them into sizable chunks(50 probes work). Kind regards, Warwick Louw -------- Original Message -------- Subject: Re: [atlas] Measurements at an interval Date: Wed, 04 Dec 2013 14:04:05 +0100 From: warwick <warwick(a)nlnetlabs.nl> To: atlas(a)ripe.net Hello, Regarding the previous email: Measurements at an interval, below is the Json constructed for the measurement: / / /{'definitions': [{'description': '', 'use_probe_resolver': False, 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': False, 'recursion_desired': False, 'target': '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168052, 'probes': [{'requested': 100, 'type': 'area', 'value': 'WW'}]}/ And below is the response: /{"error": {"code": 104, "message": "You do not have enough credit to schedule this measurement."}}/ It seems as though it's a trivial mistake, that I might actually not have enough credits to perform this measurement but I'm sure I do since it's a simple DNS query with only 100 probes. With 50 probes: /{'definitions': [{'description': '', 'use_probe_resolver': False, 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': False, 'recursion_desired': False, 'target': '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168333, 'probes': [{'requested': 50, 'type': 'area', 'value': 'WW'}]}/ This request is executed as expected. With the following response: /{u'measurements': [...]}/ (measurement id removed.) To get past this problem we have been chunking our probes in groups of 50. I just thought you might be interested. Kind regards, Warwick Louw -------- Original Message -------- Subject: [ripe.net #1113749] Re: [atlas] Measurements at an interval Date: Wed, 4 Dec 2013 15:24:32 +0100 From: Robert Kisteleki <atlas(a)ripe.net> Reply-To: atlas(a)ripe.net To: warwick(a)nlnetlabs.nl Hi, Got it, we'll look into this (probably early next week when the best person for this is back). Regards, Robert On 2013-12-04 14:09:08, warwick(a)nlnetlabs.nl wrote: > Hello, > > Regarding the previous email: Measurements at an interval, below is the > Json constructed for the measurement: > / > / > > /{'definitions': [{'description': '', 'use_probe_resolver': False, > 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', > 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': > False, 'recursion_desired': False, 'target': > '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168052, 'probes': > [{'requested': 100, 'type': 'area', 'value': 'WW'}]}/ > > > And below is the response: > > /{"error": {"code": 104, "message": "You do not have enough credit > to schedule this measurement."}}/ > > > It seems as though it's a trivial mistake, that I might actually not > have enough credits to perform this measurement but I'm sure I do since > it's a simple DNS query with only 100 probes. > > With 50 probes: > > /{'definitions': [{'description': '', 'use_probe_resolver': False, > 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', > 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': > False, 'recursion_desired': False, 'target': > '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168333, 'probes': > [{'requested': 50, 'type': 'area', 'value': 'WW'}]}/ > > > This request is executed as expected. With the following response: > > /{u'measurements': [...]}/ (measurement id removed.) > > > To get past this problem we have been chunking our probes in groups of > 50. I just thought you might be interested. > > Kind regards, > Warwick Louw > -- Robert Kisteleki, R&D Manager, RIPE NCC RIPE Atlas Team

1 0

Measurements at an interval
by warwick 13 Dec '13

13 Dec '13

Hello again, I stumbled upon something peculiar when submitting measurements with an interval via the API. It seems when submitting a measurement with a specific interval the maximum number of probes I could use was 50, but through the web interface the exact measurement is acceptable with many more probes. Kind regards, Warwick Louw

2 1

Spectrum Internet Ltd (UK) has joined RIPE Atlas anchors
by Michela Galante 11 Dec '13

11 Dec '13

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-cdf-as48294 and is hosted by Spectrum Internet Ltd in Cardiff, United Kingdom. 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(a)ripe.net

1 0

Looking for more beta testers
by Vesna Manojlovic 04 Dec '13

04 Dec '13

Dear RIPE Atlas users, we are currently testing one new feature -- alerting functionality that would enable you to incorporate results from RIPE Atlas into your nagios (or similar). There is a closed list for beta-testers, where we announce these kind of small tests, to smooth out worst bugs before enabling the feature for all the users. We would like to invite few more brave users who are willing to give us feedback on these early prototypes. If interested, please subscribe to this list: https://www.ripe.net/mailman/listinfo/atlas-testers Your applications need to be approved, so please allow several days until you get a confirmation from us. Thanks! Vesna

1 0

Credits System
by warwick 04 Dec '13

04 Dec '13

Hello, I was wondering if you please explain how the credit system works, specifically traceroute measurements. I performed 2 measurements yesterday using large packets(1500) and targeted 500 probes per experiment. When the bill came it was rather shocking. I realize this is a tall order, but is the amount correct? The measurements I'm referring to are : 1043292 and 1043293. They each totaled to 1M credits, should it not be half of that? Kind regards, Warwick Louw

2 1

A new RIPE Atlas anchor is now online
by Michela Galante 03 Dec '13

03 Dec '13

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 gr-ath-as5408 and is hosted by GRNET in Athens, Greece. 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(a)ripe.net

1 0

Six new RIPE Atlas anchors are now active
by Michela Galante 01 Dec '13

01 Dec '13

Dear RIPE Atlas users, We're happy to announce that six more RIPE Atlas anchors have joined the network: us-pao-as5580 is operated by Atrato Networks in Palo Alto, United States us-ewr-as5580 is operated by Atrato Networks in New York, United States de-fra-as5580 is operated by Atrato Networks in Frankfurt, Germany nl-dft-as31019 is operated by Meanie in Delft, Netherlands fr-sxb-as8839 is operated by SdV Plurimedia in Strasbourg, France nl-ams-as3333-2 is operated by RIPE NCC in Amsterdam, Netherlands Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors 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/ We would like to thank Job, Paul and Salim who put in a lot of effort to become the first anchor hosts! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

4 5

Space.net (DE) has joined RIPE Atlas anchors
by Vesna Manojlovic 28 Nov '13

28 Nov '13

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network. The new anchor is called de-muc-as5539 and is operated by Space.net in Munchen, 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/ 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(a)ripe.net

1 0

First RIPE Atlas anchor since production service now active
by Vesna Manojlovic 28 Nov '13

28 Nov '13

Dear RIPE Atlas users, We are proud to announce that the first RIPE Atlas anchor since this new service went into full production came online yesterday! It is situated in Munich, Germany, and is operated by Space.net. Congratulations on being the first one! Our thanks go to Gert Doering, who put in a lot of effort working alongside the RIPE NCC team through the new procedure, as well as to five other new hosts whose anchors will be activated tomorrow. From now on, we will announce each new anchor as it is activated, together with the anchoring measurements towards them. All RIPE Atlas anchors can be seen on this list and map: https://atlas.ripe.net/anchors/list/ https://atlas.ripe.net/anchors/map/ Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC

1 0

New on RIPE Labs: Map a RIPE Atlas Anchor
by Vesna Manojlovic 27 Nov '13

27 Nov '13

Dear colleagues, Please find a new article, contributed by Daniel Karrenberg, on RIPE Labs: RIPE Atlas Fun - Map a RIPE Atlas Anchor. https://labs.ripe.net/Members/dfk/map-a-ripe-atlas-anchor It shows some interesting graphs based on RIPE Atlas traceroute measurements. Kind regards, Mirjam Kuehne RIPE NCC

1 0

feature requests
by Mike. 25 Nov '13

25 Nov '13

Philip Homburg Fri Nov 22 11:08:39 CET 2013 > >Hi, > >>On 2013/11/11 19:32 , Mike. wrote: >> Allow me to disable the processing of RA's on IPv6, so that I >> can configure IPv6 statically and not have it overwritten by an >> RA. > >This feature has been requested by a handful of people. However, this >introduces more complexity in the already way too complex network >configuration of the probes. So we like to avoid implementing this >feature. Of course if there is wide spread demand for it, then we will >look into it. > >I should try it sometime, but in theory one way to give the static >address priority is to set all prefixes in the RA to deprecated. On a >'normal' network where you one prefix, it should not make a difference >for any of the other hosts. > >Philip Hi Philip, In the context of ~~I don't know what is going on inside the Atlas probe, so I'll presume an easy solution~~ ... WOuldn't a solution be to just disable the rtsol daemon when static IPv6 addresses are configured? If the probe does not issue a router solicitation request, then it won't receive RA's. Seems to me that somewhere there is a rtsol=enable that could be changed to rtsol-disable and that would resolve the issue. Configuration would still need to be done via IPv4 using DHCP in this instance. But that process is already well documented. As always, thanks for listening. Mike.

1 0

RTT Graphs for UDMs
by Alex Saroyan 25 Nov '13

25 Nov '13

Hi, As far as I understand there is no RTT history/graph for UDMs. I think it could be very usefull to have a graph storing maybe 1-6 month history of RTT for UDMs. I would really appreciate to have such a history of certain RTT values and the look for correlation with operational changes. -- Regards. /Alex Saroyan

1 0

HTTP/HTTPS probe
by Max Tulyev 22 Nov '13

22 Nov '13

Hi All, What about HTTP/HTTPS requests from Atlas probes? I hear it is technically possible. This test can provide statistics about quality and availability of certain websites, as well as the information about content is delivered unmodified, not blocked, correctly/incorrectly cached, etc. Is it possible to enable that kind of probes?

10 15

Very short uptime for some probes
by Mark Delany 22 Nov '13

22 Nov '13

Hi all. I've only been on this list for a relatively short while so this is most likely in an FAQ I should be digging thru... I've noticed that the uptime for some of the physical probes we've installed are very short. According to the control panel, one in particular has connect times of around 2-3 minutes and disconnect times of 4-6 minutes. This cycle is repeated every 10 minutes or so. All day, every day. Superficially that sort of pattern suggests some sort of continuous reboot loop. However, if I ping the probe remotely, I get just an occasional packet loss. Certainly no long gaps that you'd expect from a continuous reboot. That I can ping it remotely also suggests that external connectivity isn't the problem. Besides the periodicity is just too regular and frequent for a routing loss or similar. (In any event, if the network it's on is losing connectivity every 5 minutes I would have plenty of other symptoms.) The problem probe is also reported as getting UDMs assigned and running them so I'm not quite sure how it manages to squeeze those tests in if that connectivity status report is accurate. So my main question is, should I be concerned about the control panel connectivity reports? And if I should be, is there much I can do beyond ensuring the device has good connectivity? Mark.

3 6

Categorize probes (feature request)
by Klaus Darilion 22 Nov '13

22 Nov '13

Hi! Depending on the measurement, sometimes I want a realistic "user's view" which means using probes in residential areas, and sometimes I want a "backbone" view, which mean using probes in the back-bone (good connected) e.g. to measure my access network or my servers without the delay introduced by the probes access network. Thus, it would be cool if the probe selection algorithm allows also to choose "residential" probes or "backbone" probes. Maybe this categorization can be done automatically, or probe owners can be asked to specify the probes connectivity manually. Thanks, Klaus

11 26

UI displays of measurements
by Gilles Massen 22 Nov '13

22 Nov '13

Hi, When you visualize a measurement in the GUI, what data is used for tabs like "Probes" or "Map"? Is that the latest available data from each participating probe, or something else? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

3 3

Change account email address
by Mike. 22 Nov '13

22 Nov '13

Hi, Is there a way to change the email address that is used to log in to the RIPE Atlas site? I am talking about the email address that is the answer to the prompt: Sign in using your RIPE NCC Access account and not the alert email address used when the probe goes offline for a period of time. Thanks, Mike.

4 5

Sudden raise in UDM credit consumption
by Tarko Tikan 20 Nov '13

20 Nov '13

hey, Has there been a change how UDM probe prices are calculated? I stopped old UDM (1004320) that had following parameters: - v4 ping - 10 probes - 240 seconds, 3 packets, size 500 - 3.0 credits per result, 10800 credits per day When I created identical UDM (1040516) (UDM parameters should really be changeable to there should be possiblity to clone UDM and then modify all parameters) with double amount of probes (20) and same parameters, I'm now suddenly charged 31.25 credits per result. This does not follow the linear logic as only parameter that changed is number of probes. -- tarko

2 2

Power plugs for the Anchor nodes
by Job Snijders 15 Nov '13

15 Nov '13

Dear all, A moment of clarity occurred to me, just before I shipped out some anchor nodes: the power plugs on the back of box (C7 type) won't easily be connected in most datacenter deployments. I found these cute plugs [1], which can be ordered here [2]. Hope this helps others :-) How have others solved the issue? Any ideas on how to get these Anchors to run on 48V DC (for telco-style deployment)? Kind regards, Job [1] - http://www.kempelektroniks.nl/FilesContent/menu/menu000250/images_iecc7adap… [2] - http://shop.kempelektroniks.nl/index.php/accessories/iec-adapters.html

4 3

probe allocations
by Gilles Massen 14 Nov '13

14 Nov '13

Hi, I was wondering how the number of allocated probes is determined for a given UDM. Specifically, I set up a recurring UDM with 50 world-wide probes (DNS), but 110 probes were allocated to the test. While I'm certainly flattered that RIPE Atlas deemed the measurement so worthwhile, the credit consumption was somewhat higher than expected... so what is the logic, and am I able to get (at most) what I requested? best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

3 10

Bulk access to the measurements?
by Stephane Bortzmeyer 13 Nov '13

13 Nov '13

A colleague asks me if it is possible to have bulk access to public measurement data. (Properly: otherwise, he could dor a for loop over all measurement IDs but I suspect it is not nice.) I find nothing in the Atlas documentation. Is it because I do not search hard enough or because this possibility does not exist? #BigData

4 3

Archiving user-defined measurements in Atlas
by ivo.vdmaagdenberg＠gmail.com 12 Nov '13

12 Nov '13

Hi, Played a bit with measurements, now I want make some sensible ones and get rid of the rest. In the documentation "How do I stop a user-defined measurement?" there is mention of the 'Archive' option per measurement. I see that option but it is grayed out. The question is: What are the circumstance that grey the option? This holds for the "Forced to Stop", "Stopped" and "Ongoing" UDMs (maybe more...) Kind regards, Ivo

2 1

Feature request: Regularly Publish Names
by Daniel Karrenberg 12 Nov '13

12 Nov '13

Title: Regularly Publish Names Description: Regularly collect all IP addresses referenced in measurement definitions and all results. Reverse resolve the addresses in the DNS. Collect netnames for the addresses from the RIR registration data. Possibly collect other data such as geo-location and ASes announcing. Publish this collected data both in bulk and thru the API indexed by IP. A frequency of once every 24 hours would be sufficient to stat with. Use: When analysing measurements from the past it is important to have meta information that was current at the time of the measurement. Having this data collected in advance often also allows for more efficient analysis and more responsive tools. Perceived complexity: Low. Use hadoop to collect the list of IPs. Then run a low priority job to collect the meta data. The job also has high potential for parallelism. Perceived cost: Low. Just some cycles and storage on the back end.

1 0

need higher timeout value for ping
by Dave . 08 Nov '13

08 Nov '13

Hi, I did send a mail to atlas(a)ripe.nl. I never received an answer although it's 19 days ago. Not sure if staff is reading here, but let's see. This graph shows pings to a mobile device. A device connected to a mobile network. As mobile networks need to do paging and need some time to re-establish the radio connection, more time is needed for the packets in the first 2 or 3 seconds to get through. My request is to consider making a configurable timeout value for pings? For mobile networks a typical RTT for a first packet would be some 3 seconds. There are however buffers in a typical mobile network which store packets up to 30 seconds in case multiple pagings would fail. I really would like to be able to have a timeout maximum of just over 30 seconds but I could understand if you would limit on 5 seconds. Below, I kept a continuous ping open parallel to the Atlas tests in the marked timeframe. Therefore no paging was needed as the radio channel was kept open all the time. It seems the current timeout is 2 or 3 seconds. Regards, Dave Boonstra. [image: Inline afbeelding 1]

3 3

News about RIPE Atlas anchoring measurements
by Vesna Manojlovic 07 Nov '13

07 Nov '13

Dear colleagues, at the RIPE67 we announced that RIPE Atlas anchors are now ready for the next stage -- full production service. Since then, we already got 10 applications! Currently there are 15 anchors deployed, there is a full-mesh of measurements between the anchors, and we are scaling up the "anchoring" measurements from hundreds of probes towards each anchor, to provide the map of regional reachability. We are now looking for more interested hosts, in new locations. Please find out more details of the benefits of hosting an anchor, technical requirements and available features in RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-ripe-atl… Regards, Vesna

1 0

msm_name in DNS measurements?
by Gilles Massen 07 Nov '13

07 Nov '13

Hello, I just stumbled over a field 'msm_name' in a DNS UDM - but it's apparently undocumented (at https://atlas.ripe.net/doc/data_struct#v4540_dns ). What could it contain (except 'Tdig')? (and would it be possible to add it to the documentation?) best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473

4 5

Discussing IPv6 extension headers feature on mat-wg
by Vesna Manojlovic 06 Nov '13

06 Nov '13

Hi RIPE-Atlas-users, one of the features often requested to add to RIPE Atlas is "enable IPv6 extension headers". We would like to know the details of your needs, so please join the discussion on the MAT-WG that Jens started: https://www.ripe.net/ripe/mail/archives/mat-wg/2013-November/000364.html (I am deliberately not copying the text here, please keep the discussion on one list...) Thank you for your input! Vesna

1 0

Fwd: UDM/Credit troubles
by Alex Saroyan 01 Nov '13

01 Nov '13

Hi, I faced some troubles today using Atlas. My running credit consumption was 0 because all UDMs were stopped already for few days(screenshot attached). I have defined 2 UDMs (16 Pings from 12 Probes - nothing special - nothing big - about 300 credits) - they failed to start with no reason (screenshot attached). When defining 3-rd similar UDM, I've got message saying my current consumption is 276800 and no credit available to start an 300 credit UDM.(screenshot attached) It seems to me that some UDM is stuck, it is stopped but Atlas credit system thinks that it is running. So I faced two troubles 1-st regarding mysterious failed UDM and 2-nd regarding credit consumption. -- Regards. /Alex Saroyan

1 1

Replacing "ping RRDs" with "zoomable ping graphs"
by Robert Kisteleki 30 Oct '13

30 Oct '13

Dear RIPE Atlas users, As you may have read in the recent RIPE Labs article (https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-fe…), we've replaced the old style, RRD based visualisation for built-in ping measurements with client side, zoomable graphs. Since then we've also changed the graphs that represent the probe's bandwidth usage. The new graphs have the benefit that they retain all details, even for longer time intervals. (These details were lost in the RRD based graphs over time.) Other reasons why we changed include that generating the RRD graphs did not scale well with the increasing number of RIPE Atlas probes, and making them required us to maintain a large set of backend servers, each being a single point of failure. With the new approach you still have visualisations for this information, with more details and interactivity (though it does require running JavaScript on the client side). We'll change the remaining RRDs to this new model as well in the coming period, and stop generating the RRD based images altogether. We expect to stop with the "built-in pings" and the probe traffic RRDs first, likely in the second week of October. If you would like to embed these new style visualisations into your pages (maybe because you used the RRD graphs before), then you'll have to embed a RIPEstat widget; see https://stat.ripe.net/widgets/demo/atlas_probe_widgets.html for details. Regards, Robert Kisteleki for the RIPE Atlas team

1 1

Strong doubts about the option "DNS recursion"
by Stephane Bortzmeyer 28 Oct '13

28 Oct '13

I fear that the option "recursion_desired" <https://atlas.ripe.net/doc/measurement-creation-api/> does not work as expected. Here was my experiment. I registered a new domain name which never appeared before, d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. Because of its unreadability, there is zero chance it has ever been in a DNS cache. I then ask Atlas probes to dig it, with "recursion_desired" set to false: {'definitions': [{'query_class': 'IN', 'use_probe_resolver': True, 'af': 4, 'query_argument': 'd7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr', 'query_type': 'TXT', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': False, 'description': 'DNS resolution of d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr'}], 'probes': [{'requested': 10, 'type': 'area', 'value': 'WW'}]} But all the probes got the content of this TXT record! Measurement #1034372 if you want to check (unfortunately, this parameter is not displayed in <https://atlas.ripe.net/atlas/udm.html?msm_id=1034372>). It seems wrong, they should all have retrieved an empty answer (here, with dig, the behaviour I expected): % dig +norecurse @MYSERVER TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse @relay1 TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33141 ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 21 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. IN TXT ;; AUTHORITY SECTION: fr. 165392 IN NS d.ext.nic.fr. fr. 165392 IN NS d.nic.fr. ...

4 11

Huge credit debit
by Mike. 12 Oct '13

12 Oct '13

One of my measurements (that usually uses about 1000 credits per day) all of a sudden posted a credit usage of 2,293,788.00 credits for a single measurement. 2013-10-10 18:13 UTC UDM 764596 samples of msm #1013277 -2,293,788.00 -1,279,520.00 I don't know where or why the 764596 samples came from, usually only 90 samples are performed. Was there a proble in the measurement or credit system recently? Thanks.

3 6

Problems with one-off measurements
by Robert Kisteleki 07 Oct '13

07 Oct '13

Dear RIPE Atlas users, It has come to our attention that one-off measurements at the moment don't produce the expected number of results. So far our investigation shows that this is most likely a probe firmware issue. We'll let you know once we find the real cause and have a fix for this. In the meantime please accept our apologies for the reduced usefulness of this function. Regards, Robert Kisteleki for the RIPE Atlas team

1 1

Question about rt definition of DNS measurements
by Klaus Darilion 06 Oct '13

06 Oct '13

Hi! When doing DNS measurements I see that the average "rt" time is considerable higher when setting the DO bit. When I check my name servers manually with dig (with and without DO) I do not see any considerable differences. Thus, I wonder how "rt" is measured in the Atlas probes and if the probe does some DNS/DNSSEC relevant processing during the "rt" interval, or is it really just the time between sending and receiving of the packets on IP layer? Thanks Klaus

2 1

Announcing RIPE Atlas Service Terms Documentation for Anchor Hosts
by Vesna Manojlovic 03 Oct '13

03 Oct '13

Dear colleagues, In the process of transitioning RIPE Atlas anchors towards being a production service, we have developed two documents that describe the service terms: - Draft RIPE Atlas Service Terms and Conditions - Memorandum of Understanding - Hosting a RIPE Atlas Anchor Probe Please see the details in this RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-terms-and-conditions If you are currently hosting an anchor, or if you are interested in hosting a RIPE Atlas anchor in the future, we would like to hear any feedback you have on these draft documents. Our goal is to finalise the documents by 11 October so that we can announce the production service at the upcoming RIPE 67 Meeting in Athens. Regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

Measurement of impact of the Russian censorship
by Max Tulyev 03 Oct '13

03 Oct '13

Hello Atlas, recently I found some of Websites was blocked in Ukraine with PutinWall outside Russia. These resources was not hosted in Russia as well. Further investigation shows that the trace to these resources are either through Russia, or (which is more interesting) through Russian-based carriers which are do filtering on their networks boundary which are outside Russia as well, for example, in Frankfurt. This is some impaced nets in Ukraine, but probably countries whole connected through Russia, like Kazakhstan, are more suffering. Is it possible to use Atlas probes to figure out impact of PutinWall to countries should not be impacted by Russian censorship? And may be the efficient of filtering inside Russia? That's the sample of censored URL: http://stervozzinka.dreamwidth.org/15580.html The task is to probe it from Atlas probes and put on map the mark is it accessible or not for the first result. The second stage is to figure out carriers do the filtering of trans-Russia connectivity. I believe it will be interesting for a lot of people. I see this test is possible, but possible only manually by the RIPE NCC staff.

1 0

Problems deleting measurements
by Klaus Darilion 03 Oct '13

03 Oct '13

Hi! I have problems with lots of measurements, I can not delete them. e.g: A) https://atlas.ripe.net/api/v1/measurement/1027747/ The status is "Failed" and in the web I can not Archive or Stop it. Also deletion via REST fails: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1027747/?key=01....6d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} btw: is above REST call correct? Same problem for measurment 1012558 which is in status Stopped. B) Is "archive" in the web interface identical to "DELETE" via REST? E.g. the web interface offers me "Archive" for measurement 1029338 (and I am quite sure it would work), but the REST call fails with same result: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1029338/?key=01....d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} Further, the web interface offers "Stop" and "Archive", but the REST call only offers "DELETE". So, how do I "Stop" via REST? For me it is confusing to have different terms in the web interface and REST API. C) 1031725: The measurement is currently (UTC 18:30) in status Ongoing. Start Time is UTC 19:45, Stop Time is 19:55. When I stop the measurement, the measurements stop time changes to the current time, but status is still Ongoing, and I can not Archive (not offered), but it still offers always Stop. But when I delete via REST, the measurement gets stopped (status Stopped in web interface). So does REST-DELETE is identical to "Stop" in web interface? If yes, how do I archive via REST? Further, DELETE a stopped message should not produce error "That measurement cannot be stopped.", but rather "That measurement is already stopped." D) For the web interface it would be cool to stop/archive/delete measurements more comfortable. Eg. select multiple measurements and then choose "stop and archive". Thanks Klaus Thanks Klaus

2 2

Probe uptime reporting issues
by Robert Kisteleki 01 Oct '13

01 Oct '13

Dear All, On 21 September we deployed a new software version on our core infrastructure components. Unfortunately this contained a bug that we didn't catch in time, which caused "probe uptime reports" not to be propagated properly. This affected the "monthly probe uptime reports" as well as -- in some cases -- the amount of credits received for a probe. We've fixed the bug and re-sent the missing uptime entries. Please let us know (in an email to atlas(a)ripe.net, mentioning your email address and probe ID) if you received less credits than you should have, and would like to receive compensation. In order to improve our process, we're working on an internal test suite that will help us catching these kind of errors in time. We aplogise for the inconvenience this issue may have casued. Regards, Robert Kisteleki for the RIPE Atlas team

1 0

Credits transfer no longer working?
by Stephane Bortzmeyer 30 Sep '13

30 Sep '13

Did anyone notice problems with credit transfers? I run a RIPE Atlas workshop tomorrow abnd I tried to transfer credits to attendants, people with a RIPE account, both in the same LIR and outside. Nothing is credited on their side.

4 4

finding a probe
by Randy Bush 27 Sep '13

27 Sep '13

remote hands plugged an old style probe in. i see it on the ether port they claimed, its mac is 00:80:a3:91:4b:0d (my others are all 00:20, hmmm) i plug the dhcp-issued address 198.180.152.27 into the page at https://atlas.ripe.net/register/ it tells me there is no probe there how to debug? randy

1 0

REST API Problems for DNS measurements with DO and TCP
by Klaus Darilion 26 Sep '13

26 Sep '13

Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with { "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_EDNS0": false, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], } but that does not work - the generated measurements do not use TCP and DO. When I create the measurement via the web interface and review the measurement via the REST API, I see that other properties are set: "do" and "protocol". E.g: # curl https://atlas.ripe.net/api/v1/measurement/1027747/ {"all_scheduling_requests_fulfilled": true, "can_visualise": false, "creation_time": 1380018470, "description": "TEST via WEB", "do": true, "dst_addr": "194.0.25.13", "dst_asn": "1921", "dst_name": "194.0.25.13", "interval": 240, "is_oneoff": true, "is_public": true, "msm_id": 1027747, "nsid": true, "participant_count": 1, "protocol": "TCP", "query": {"class": "IN", "type": "SOA", "value": "versicherung."}, "resolve_on_probe": false, "resolved_ips": ["194.0.25.13"], "result": "/api/v1/measurement/1027747/result/", "start_time": 1380018470, "status": {"id": 7, "name": "Failed"}, "stop_time": 1380018904, "type": {"id": 6, "name": "dns"}, "udp_payload_size": 512} So I tried to create measurements with the "do" and "protocol" properties, but these properties are again ignored. If I am doing something wrong, so please give me some hints. Otherwise the API documentation is wrong and these properties can not be set via REST, only via the web interface - and should be fixed. Thanks Klaus

3 6

IPv6, RA and static IPv6 assignment
by Mike. 19 Sep '13

19 Sep '13

Are there any plans to allow the probe's listening for RA to be disabled so that I can configure a static IPv6 address, router and DNS server without RA overwriting my values?

4 4

Add E-Mail notification when a probe is back up (for more than 60 minutes)
by Roman Mamedov 19 Sep '13

19 Sep '13

Hello, Got one of these: > Your probe 73 has been disconnected since 2013-09-19 09:26:19 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 60 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/atlas/myprobes.html, click on "My Probes" and then on probe 73. In the opened tab, select "Probe's Settings" and then "Notifications" to change your settings. > > Kind regards, > > RIPE Atlas Team > What's unusual this time, is that I did not change anything in my network setup, and I can still ping the probe both on its local v4 and global v6 addresses. So one way of action would be to unplug and replug the probe in hope that it sorts out itself; 2nd course of action would be to simply wait and see if it reconnects on its own. If I choose this, I have to keep the Atlas website open in a browser tab, refreshing from time to time to see if the readings changed to "Connected". So what baffles me about this, why can't I get a simple E-Mail notification same way as "it went down", to tell me that "ok now it's back up"? -- With respect, Roman

1 0

"Spoofing" tests.
by Warren Kumari 18 Sep '13

18 Sep '13

Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. W --- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams

11 17