- ripe-atlas - mailman.ripe.net

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

RIPE Atlas anchors update
by becha 16 Sep '13

16 Sep '13

Dear RIPE Atlas users, we are happy to share with you the results of the pilot phase of RIPE Atlas anchors, and plans for the production service. Two recent RIPE Labs article give you the details: * technical results of virtualization testing: https://labs.ripe.net/Members/romeo_zwart/further-virtualisation-testing-fo… * "mesh" measurements between all anchors, moving to smaller box and different hardware platform, and making the service for all, not only members: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-summary-and-ne… We are looking forward to see you at RIPE67, MAT-WG, and in the meantime, to your comments and feedback on this list. Kind regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

No IPv6 Connection on Probe
by David Churchill 13 Sep '13

13 Sep '13

I've noticed that my probe (12070) has not had any IPv6 connectivity for the last several days. I've reset the probe a couple of times and verified that my internet service still has full IPv6 connectivity (@http://test-ipv6.comcast.net/). Is there anything I can do to restore the IPv6 connectivity? Thanks, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill(a)comcast.net

2 1

A small matter of terminology
by Stephane Bortzmeyer 10 Sep '13

10 Sep '13

A long time ago, there was only one sort of measurement. Then, one-off measurements were created. How do we call the other category? Periodic measurements? Repeated measurements?

1 0

New On RIPE Labs: The Seismograph And Other RIPE Atlas Features
by Michela Galante 09 Sep '13

09 Sep '13

Dear colleagues, We have added a couple of new RIPE Atlas features including the Seismograph, zoomable ping graphs and others. You can find the details in an article on RIPE Labs here: https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-fe… Kind regards Michela Galante Project Coordinator RIPE NCC

1 0

Using Atlas for commercial services
by Stephane Bortzmeyer 05 Sep '13

05 Sep '13

Hello, happy Atlasers, After reading <https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services> (specially the part about using Atlas to monitor reachability from Nagios), the ToS <https://atlas.ripe.net/service-rules/> and checking the FAQ <https://atlas.ripe.net/about/faq/>, I still have a question: Can I use Atlas as a basis for commercial services? Today, most Atlas uses seem to be for public research, or for "selfish" measurements (checking my network). But I see nothing forbidding people to sell services (monitoring, quality assessment) to other people, based on Atlas. Is it on purpose? [Yes, I have one or two business ideas and I would like to know before I continue developing them.]

11 15

Re: [atlas] Using Atlas for commercial services
by Hook 05 Sep '13

05 Sep '13

As already said, commercial usage would also mean that you have to earn credits in some way. As far as I know, it's only possible to earn credits by - hosting probes itself - sponsoring new probes - getting a LIR In either of the first two cases, the atlas project will benefit from it. The third one is a special case and isn't worth a discussion. So I think we should allow commercial usage of the Atlas project, if commercial usage still means to support the Atlas project itself because of the need for credits! Would be a win-win situation. Michael 2013/9/5 Daniel Karrenberg <daniel.karrenberg(a)ripe.net> > > On 05.09.2013, at 11:42 , Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: > > > On Thu, Sep 05, 2013 at 05:22:50PM +0800, > > Sanjeev Gupta <ghane0(a)gmail.com> wrote > > a message of 107 lines which said: > > > >> Adam Smith was right, the baker and the butcher feed me by being > selfish. > > > > So, apparently, there is no consensus among the Atlas community. An > > interesting discussion to have in Athens? > > It is a discussion we should have in the mat-wg. The working groups work > on the mailing lists; physical meetings are just focal points for the work. > > Daniel > > >

1 0

Disabling one measurement on my probe...
by Warren Kumari 02 Sep '13

02 Sep '13

Hi all, Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times. I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and 2: did anything change recently with the "Ping" measurement, like the packet size for example? I *did* spend some time reading the list archives and documentation, but was not able to find an answer. W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect… -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett

4 4

Data visualization not working?
by Max Grobecker 29 Aug '13

29 Aug '13

Hi, is there any known reason/issue why new created measurements don't visualize the data? I'm pretty sure I ticked the "Visualize Data" box when creating a new measurement, but when I open my new measurement, the "RRD" tab is missing and in the settings the "Visualize" box is unchecked :-( Is it just me or do other people have the same issue? Greetings, Max

2 2

Reddit?
by Daniel Quinn 29 Aug '13

29 Aug '13

Hello everyone, I'm one of the developers on the RIPE Atlas project and I'm hoping some of you can help me figure out if we should have a presence on [Reddit](http://www.reddit.com/) and if so, where. I'm a pretty active member of that community, so I was appointed to ask the lot of you if we should bother setting up a subreddit, or if we should just frequent any particular subreddit to answer questions and/or promote RIPE Atlas. So, does anyone reading this fancy the idea of better outreach on Reddit? And if so, in what way would you recommend? Feel free to post your responses to the list, or just respond to me directly. We'll let you know if we decide to branch out in this way.

3 4

Success stories to share at RIPE67?
by Vesna Manojlovic 27 Aug '13

27 Aug '13

Hi RIPE Atlas active hosts & users, I know of two RIPE Atlas related talks that are still being considered for RIPE67 -- and there might be more! Do you have a success story to share? Plenary-talks CallForPapers is extended, and then there are working-group sessions too, MAT-wg being the most typical, but in the past there were presentations on using RIPE Atlas in IPv6-WG and DNS, and Routing-WG... If you need help with preparing slides, or doing extra measurements to prove your tests - do let us know! Good luck if you decide to present, and see you at RIPE67! Regards, Vesna -------- Original Message -------- Dear Colleagues, A list of currently accepted RIPE 67 Plenary talks, BoFs, Tutorials and Workshops is now published at: https://ripe67.ripe.net/programme/meeting-plan/draft-programme/ There are still few slots remaining for a final RIPE 67 programme and RIPE Programme Committee will accept new proposals until *9 September 2013*. This is our last call for you to submit your proposals. See https://ripe67.ripe.net/programme/cfp/ or find the original CFP below. Kind regards Filiz Yilmaz for RIPE Programme Committee ------------------ Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 67 will take place from 14-18 October 2013 in Athens, Greece. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary session presentations, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 67. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: * 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 Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. The RIPE PC accepts proposals for different presentation formats, including plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. See the full descriptions of these formats at https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/ Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several time slots for "lightning talks", which are selected immediately before or during the conference. The following general requirements apply: * Proposals for plenary session presentations, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 4 August 2013, using the meeting submission system (https://ripe67.ripe.net/submit-topic/) Proposals submitted after this date will be considered on a space-available basis. * Lightning talks should also be submitted using the meeting submission system (https://ripe67.ripe.net/submit-topic/) and can be submitted just days before the RIPE Meeting starts or even during the meeting week. The allocation of lightning talk slots will be announced in short notice - in some cases on the same day but often one day prior to the relevant session. * Presenters should indicate how much time they will require. See more information on time slot allocations per presentation format (https://ripe67.ripe.net/programme/i-want-to-present/presentation-formats/) * Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panelists, presenters and moderators. * Due to potential technical issues, it is expected that most, if not all, presenters/panelists will be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net.

1 0

Garbage Measurements
by Michael Stevens 26 Aug '13

26 Aug '13

Hello, at the moment I'm seeing a lot of measurements on my both probes, that doesn't have any live target and, sometimes, have even invalid targets like 2001:db8:0:dead:beef::1 which is part of the IPv6 for documentation purposes. I've made a screenshot here: http://i.imgur.com/PRXHsOZ.png Can someone from RIPE check this out? Not sure if there is someone abusing RIPE Atlas in a nasty way. Michael

5 5

Crediting for probe uptime
by Robert Kisteleki 23 Aug '13

23 Aug '13

Dear All, In the last two days we noticed a hickup in the crediting procedure (the one that gives credits to probe hosts and sponsors). We believe the proper fix is in place now. We just finished crediting everyone for the time period in question, which means all of the probes generated more than usual credits -- compensating for the missing ones lately, and some interest :-) We apologise for the inconvenience this may have caused. Regards, Robert Kisteleki

1 0

On RIPE Labs: Future of the RIPE NCC technical services
by Vesna Manojlovic 23 Aug '13

23 Aug '13

Dear colleagues, please take a look at the Labs article by Kaveh Ranjbar, which touches upon the future of the RIPE Atlas services: https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services Regards, Vesna

1 0

IPv6 Report - Blank
by Tom Kacprzynski 22 Aug '13

22 Aug '13

Hello, Is anyone else having the issue of downloading IPv6 measurement reports? I ran few of them and the file is empty. I tried downloading both formats JSON and Fragment. I also tried downloading the public measurement without any luck either. Thanks -- *Tom Kacprzynski*

2 2

Geo locations confirmed
by Marco Davids (SIDN) 20 Aug '13

20 Aug '13

Hi, Are any of the geo-locations of Atlas probes confirmed, double-checked, or verified by RIPE? Or do we just have to take for granted, whatever the owner of the probe enters in the probe's settings ? Thanks, -- Marco

2 1

v3 Probe got disconnected and won't reconnect
by Axel Fischer 14 Aug '13

14 Aug '13

Hi, on 2013-08-11 at 05:15:30 UTC one of our probes (ID: 11707) got disconnected. It is connected via a switch to a router within our network. I can see the link up (it remained up all the time) but see the 3rd LED (Network Test) and 4th LED (Connecting) blinking. The MAC was visible on the switch port and router. I powercycled the probe but no change except that the MAC is no longer visible on the router. With a laptop instead of the probe it works fine. Is the probe broken? How can this state be fixed? Regards, Axel -- Axel Fischer Network Engineer 1&1 Internet AG Brauerstrasse 48 D-76135 Karlsruhe http://www.1und1.de (AS8560) Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian Würst Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese Email. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This E-Mail may contain confidential and/or privileged information. If you are not the intended recipient of this E-Mail, you are hereby notified that saving, distribution or use of the content of this E-Mail in any way is prohibited. If you have received this E-Mail in error, please notify the sender and delete the E-Mail.

3 2

Probe sharing
by Martin Stanislav 08 Aug '13

08 Aug '13

Hi, This spring RIPE Atlas update [1] introduced a new feature called probe sharing. Probe sharing should work for colleagues within the same LIR and is to be set via: "My Probes" -> "Probe's Settings" -> "General Configuration" -> Select your LIR in the "Share with" field. I've set the "Share with" field to our LIR ID for all three local probes. But a colleague of mine, in spite of being able to login to the Lirportal, sees an error message below every time he tries to access the probe list at https://atlas.ripe.net/atlas/myprobes.html The error message: "You are not logged in as a RIPE NCC member". Is there anything I've missed? Possible delay in privilege propagation from the Lirportal to Atlas section? Thanks. Martin [1] https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-april-2013

4 4

Multiple Probe v3 Disconnects
by David Churchill 08 Aug '13

08 Aug '13

I just received my v3 probe 3 days ago and I've noticed on the status page that that there are quite a few disconnects: Disconnect at: Connected time: Disconnected time: (still connected) 0d, 0h, 30m (still connected) 2013-08-08 11:37:44 UTC 0d, 0h, 38m 0d, 0h, 2m 2013-08-08 10:49:09 UTC 0d, 1h, 14m 0d, 0h, 10m 2013-08-08 09:31:38 UTC 0d, 2h, 2m 0d, 0h, 3m 2013-08-08 07:25:41 UTC 0d, 1h, 22m 0d, 0h, 3m 2013-08-08 05:53:24 UTC 0d, 1h, 26m 0d, 0h, 9m 2013-08-08 04:24:56 UTC 0d, 2h, 23m 0d, 0h, 2m 2013-08-08 01:57:23 UTC 0d, 1h, 18m 0d, 0h, 4m 2013-08-08 00:35:09 UTC 0d, 0h, 26m 0d, 0h, 3m 2013-08-08 00:05:53 UTC 0d, 1h, 25m 0d, 0h, 2m 2013-08-07 22:37:14 UTC 0d, 1h, 12m 0d, 0h, 3m 2013-08-07 21:20:56 UTC 0d, 0h, 4m 0d, 0h, 4m 2013-08-07 21:11:44 UTC 0d, 2h, 9m 0d, 0h, 4m 2013-08-07 18:59:32 UTC 0d, 0h, 39m 0d, 0h, 2m 2013-08-07 18:18:40 UTC 0d, 6h, 12m 0d, 0h, 1m 2013-08-07 12:03:56 UTC 0d, 12h, 42m 0d, 0h, 1m 2013-08-06 23:19:16 UTC 0d, 0h, 4m 0d, 0h, 2m 2013-08-06 23:15:08 UTC 0d, 0h, 2m 0d, 0h, 0m 2013-08-06 23:05:16 UTC 0d, 4h, 45m 0d, 0h, 7m 2013-08-06 18:17:13 UTC 0d, 1h, 54m 0d, 0h, 2m 2013-08-06 16:18:39 UTC 0d, 0h, 45m 0d, 0h, 3m 2013-08-06 15:32:39 UTC 0d, 0h, 41m 0d, 0h, 0m 2013-08-06 14:50:33 UTC 0d, 2h, 32m 0d, 0h, 0m 2013-08-06 05:51:43 UTC 0d, 6h, 47m 0d, 6h, 25m Is this something I should be concerned about? If so, could it have to do with the fact that my probe is plugged into a 10/100/1000 MBit switch (I saw an earlier thread that suggested this might be an issue)? If the Gigabit switch is a problem, would it help if I cascade a 10/100 switch off one of the Gigabit switch's ports, or off one of my router's ports (which are all Gigabit) and then plug the probe into that 10/100 switch? Finally, I'm using a cell phone charger for power, it's 5V, mini-usb, I don't think that should cause an issue should it? Thanks for any help, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill(a)comcast.net

3 4

1000Base-T not supported?
by Tore Anderson 08 Aug '13

08 Aug '13

Today I was struggling to get a v3 probe (TP-Link) connected to my network, the link just wouldn't come up. On a whim I tried connecting it to a tri-rate 10/100/100Base-T device, and lo and behold - it came alive! Only 100Mb, though. Is it really the case that the probes don't support 1GbE? The probe has «150Mb» printed on it, which strikes me as rather odd if it's limited upwards to 100Mb. Tore

3 4

RIPE Atlas maintenance on Tuesday, 6 August
by Robert Kisteleki 06 Aug '13

06 Aug '13

Dear RIPE Atlas users, We'd like to let you know that we plan to perform scheduled maintenance on the RIPE Atlas central infrastructure on Tuesday, 6 August, for a couple of hours during the day. In this period, main features including the RIPE Atlas user interface (atlas.ripe.net) data downloads and measurement scheduling functions will be unavailable. Probes will continue to work and all results will still be collected or buffered; however, during the maintenance period you will be unable to log in to the website, manage your probes/measurements, or get to result data/visualisations. We apologise for any inconvenience this may cause. Regards, Robert Kisteleki

1 1

Probe no longer on an IPv6 network?
by Rusty Dekema 05 Aug '13

05 Aug '13

Good evening, When I first installed it, probe 10555 was on a network which supports IPv6. Since then, I have moved it to a different network which does not have IPv6 access at all. Is there something I should do to let the RIPE Atlas system know that it no longer has IPv6 access? It seems like there should be, but I haven't found it. I would not like for it to be one of those probes which "thinks" it has IPv6 but actually does not... Thanks, Rusty D

2 1

adding a device
by folkert 05 Aug '13

05 Aug '13

Hi, Yesterday I received a probe-device at a conference. I entered the details in the website (which was a lot of fun: finding out the ipv4 prefix(?!) - I ended up trying a couple of entries found in the whois info of my ipv4 address, also in what format should I enter the mac-address?) but the device does not appear in the "My probes" list. Even after a couple of hours. I verified that it got an ip4-address from the dhcp server and also radvd is happily announcing the ipv6-prefix in that segment. Furthermore: I see that the probe is doing all kinds of network traffic to the internet. So the device at itself seems to work. What can be wrong? Folkert van Heusden -- Always wondered what the latency of your webserver is? Or how much more latency you get when you go through a proxy server/tor? The numbers tell the tale and with HTTPing you know them! http://www.vanheusden.com/httping/ ----------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

3 3

Registering a new probe...
by Chris Elliott 31 Jul '13

31 Jul '13

I have one probe (3690), and just received two new probes from Nathalie Trenaman, thanks to Bert Wijnen. However, either I'm just flat out missing something or the registration page is broken. I go here: https://atlas.ripe.net/register/ I ensure I'm logged in, and try to complete the registration process. No matter what, it always says: - There were some problems with your submission. Please see below However, nothing is highlighted or otherwise called out as an issue. I've tried various combinations in various fields, with no success. Here's one of the settings I've tried: - On what sort of network will you be installing the probe? * Residential/Consumer Business Network Educational Network IXP RIPE NCC Member (LIR) - Organisation Name * - What's the connection speed like on that network? * < 1 Mb/s 1-4 Mb/s 5-9 Mb/s 10-19 Mb/s 20-49 Mb/s 50-99 Mb/s 100-499 Mb/s 500-999 Mb/s > 1 Gb/s I don't know - AS Number - My network supports IPv4 - IPv4 Network Prefix - Please enter a valid prefix. - My network supports IPv6 - IPv6 Network Prefix - How did you receive your probe? * From conference/training From sponsor Other - Who is the sponsor? * - MAC Address - Location * <http://maps.google.com/maps?ll=21.351893,-102.718887&z=2&t=m&hl=en-US&mapcl…> Map data ©2013 MapLink - Terms of Use<http://www.google.com/intl/en-US_US/help/terms_maps.html> Map Satellite - I'm willing to keep the probe online 24/7 - I'm willing to make my probe visible to the public - I accept the rules of the game a.k.a. Pilot Service Rules<https://atlas.ripe.net/service-rules/> * Thanks for looking into this issue. Chris. -- Chris Elliott chelliot(a)pobox.com

2 2

HTTP or not HTTP?
by Stephane Bortzmeyer 31 Jul '13

31 Jul '13

I'm surprised to see in UDM documentation that you can do HTTP measurements: https://atlas.ripe.net/doc/udm#http-http6 But I do not find this option in the "Choose a measurement" menu of the Web interface. And it is not documented in the REST API: https://atlas.ripe.net/doc/measurement-creation-api/ > type: One of ping,traceroute,dns or sslcert So, can we do HTTP measurements with the Atlas probes?

2 3