From sebastian at nzrs.net.nz Wed Apr 1 02:37:51 2015 From: sebastian at nzrs.net.nz (Sebastian Castro) Date: Wed, 01 Apr 2015 13:37:51 +1300 Subject: [atlas] Finding out the number of simultaneous measurements Message-ID: <551B3DDF.5010009@nzrs.net.nz> Hi: While running some measurements for a research work we are doing, I encountered this error "You can't have more than 100 simultaneous measurements". I'm not surprised, because I have some long term measurements running, but the bulk of them are one-off. Although I could throttle my measurements in little batches, I would prefer a way to programmatically query Atlas and find out how many measurements I'm running. The API allows you to get the list of public measurements, but running the query with an API key for my account doesn't change the output. Is there a way to do this with the API? Cheers, -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535 From robert at ripe.net Wed Apr 1 02:55:31 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 31 Mar 2015 17:55:31 -0700 Subject: [atlas] Finding out the number of simultaneous measurements In-Reply-To: <551B3DDF.5010009@nzrs.net.nz> References: <551B3DDF.5010009@nzrs.net.nz> Message-ID: <551B4203.2070509@ripe.net> On 2015-03-31 17:37, Sebastian Castro wrote: > Hi: > > While running some measurements for a research work we are doing, I > encountered this error "You can't have more than 100 simultaneous > measurements". I'm not surprised, because I have some long term > measurements running, but the bulk of them are one-off. Although I could > throttle my measurements in little batches, I would prefer a way to > programmatically query Atlas and find out how many measurements I'm running. > > The API allows you to get the list of public measurements, but running > the query with an API key for my account doesn't change the output. > > Is there a way to do this with the API? > > Cheers, We can definitely make this possible (basically, it needs a filter "my measurements", the rest is there), but in the meantime, you can try visiting https://atlas.ripe.net/atlas/user Cheers, Robert From elane at ripe.net Thu Apr 2 14:44:48 2015 From: elane at ripe.net (Eamonn Lane) Date: Thu, 2 Apr 2015 14:44:48 +0200 Subject: [atlas] TNNet Oy Ltd (FI JYV)has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fi-yyv-as30798 and is hosted by TNNet Oy Ltd in Jyvaskyla, Finland. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From pvlaar at afilias.info Wed Apr 8 17:15:00 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Wed, 08 Apr 2015 17:15:00 +0200 Subject: [atlas] list of country codes / UDM via API limit Message-ID: <552545F4.9030605@afilias.info> Hi all, is there a list of country codes that have active probes in them? I've used the ISO3166 list but am finding that many CCs do not have probes in them, so setting up those UDMs is moot. I am also running into what appears to be the limitation of the amount of UDMs that I'm allowed to setup using the API: around 25. Has anyone else run into that limit? Is there a way to raise that limit somehow? Thanks, ~paul From v.bajpai at jacobs-university.de Wed Apr 8 23:42:44 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 8 Apr 2015 21:42:44 +0000 Subject: [atlas] survey on performance measurement platforms and related standards Message-ID: <75863780-A1CF-42B7-A3EE-FE5179E533A2@jacobs-university.de> Dear RIPE Atlas WG, I would like to share something with you today. As you know, IETF LMAP [1] is making efforts to standardize large-scale measurements to allow divergent measurement platforms to converge towards interoperability. Early discussions within this group often lead to folks asking for feature sets and possibilities of each contemporary performance measurement platform. So we started digging literature work in this space and found that although there were surveys on topology-based measurement platforms (such CAIDA Ark et al.); literature work on performance measurement platforms (such as RIPE Atlas, SamKnows et al.) was missing. Therefore, we started writing such a survey in 2013 to plug this gap and also complement this with current state of IETF standardization efforts happening within the LMAP and IPPM working groups. This work got published and came online this week. I thought would share this with you: ----------------8<-----------------8<-----------------8<-----------------8< A Survey on Internet Performance Measurement Platforms and Related Standardization Efforts Vaibhav Bajpai, J?rgen Sch?nw?lder IEEE Communications Surveys & Tutorials April, 2015 A number of Internet measurement platforms have emerged in the last few years. These platforms have deployed thousands of probes at strategic locations within access and backbone networks and behind residential gateways. In this paper we provide a taxonomy of these measurement platforms on the basis of their deployment use-case. We describe these platforms in detail by exploring their coverage, scale, lifetime, deployed metrics and measurement tools, architecture and overall research impact. We conclude the survey by describing current standardization efforts to make large-scale performance measurement platforms interoperable. DOI: http://dx.doi.org/10.1109/COMST.2015.2418435 Author Copy: http://vaibhavbajpai.com/documents/papers/proceedings/lsmp-comst-2015.pdf ----------------8<-----------------8<-----------------8<-----------------8< Thanks! [1] https://datatracker.ietf.org/wg/lmap Best, Vaibhav ===================================================== Vaibhav Bajpai Research I, Room 91 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dquinn at ripe.net Thu Apr 9 15:05:29 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 09 Apr 2015 15:05:29 +0200 Subject: [atlas] list of country codes / UDM via API limit In-Reply-To: <552545F4.9030605@afilias.info> References: <552545F4.9030605@afilias.info> Message-ID: <55267919.7050907@ripe.net> We don?t currently have a complete list of probes-per-country, but here?s a quick dump of what I found in our database. Note that this list includes probes currently connected, disconnected, and assumed abandoned: |US 1297 DE 1213 FR 984 RU 890 GB 885 NL 634 UA 423 CZ 313 IT 308 BE 287 CH 274 PL 232 CA 230 ES 224 SE 195 AT 189 DK 166 IE 160 BG 147 NO 142 ZA 132 AU 130 JP 125 GR 124 FI 115 IR 101 SG 97 BR 89 HU 84 NZ 83 RO 78 PT 77 HR 71 RS 64 CN 59 MY 57 KZ 56 LU 50 SI 46 IN 45 TR 45 SK 40 MK 36 IL 36 LK 35 BY 35 CL 34 AR 32 EE 32 BD 29 MD 29 AM 29 LV 28 AL 28 LT 28 KE 23 AE 22 PK 22 AZ 22 TH 21 BJ 21 SC 20 KR 20 SA 19 ID 17 PH 17 TN 17 UY 17 IQ 16 RW 16 HK 15 KW 14 GE 13 TZ 13 MX 13 SD 13 CI 13 BA 13 CG 12 AD 12 UG 12 NC 11 IS 10 SN 10 MA 10 DZ 10 NP 10 CM 10 MT 10 GM 10 TW 9 BF 9 MZ 9 CY 9 UZ 9 ZW 9 MU 9 VE 9 CO 8 VN 8 LB 8 DO 8 BT 8 LR 8 ET 7 QA 7 JO 7 NA 7 ZM 7 TT 7 GP 6 NG 6 CR 6 GT 6 RE 6 BH 6 BW 6 EC 6 GH 6 MG 6 AO 6 KG 6 TG 5 MW 5 PE 5 LI 5 MM 5 YE 5 CW 5 FO 5 BI 5 ME 5 EG 5 NE 5 GD 4 KH 4 VU 4 TJ 4 JM 4 MN 4 GL 4 HN 4 PR 4 CD 3 NI 3 IM 3 LS 3 MR 3 SV 3 GA 3 SZ 3 DJ 2 SM 2 BQ 2 LY 2 PY 2 FJ 2 GF 2 JE 2 PG 2 WS 2 MC 2 SR 2 AF 2 MQ 2 SJ 2 OM 2 TD 2 AQ 1 BM 1 LA 1 MV 1 PA 1 GQ 1 KI 1 ML 1 AS 1 CU 1 KM 1 SO 1 CV 1 FM 1 GG 1 KN 1 TM 1 CK 1 GU 1 SS 1 AX 1 GI 1 NR 1 TO 1 BZ 1 KY 1 BL 1 MH 1 PS 1 | ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Thu Apr 9 17:09:23 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 09 Apr 2015 17:09:23 +0200 Subject: [atlas] list of country codes / UDM via API limit In-Reply-To: <552545F4.9030605@afilias.info> References: <552545F4.9030605@afilias.info> Message-ID: <55269623.8020602@ripe.net> Hi Paul, to answer the second part of your question: On 08-apr.-15 17:15, Paul Vlaar wrote: > > I am also running into what appears to be the limitation of the amount > of UDMs that I'm allowed to setup using the API: around 25. the actual number is 100, so it looks like you have run into another limit -- as you reported in an email to us. I've fixed it for you, but I will get back to you personally about this. If this does not help, please open the ticket with some more details - measurements IDs, error reports you get back, your account name... > Has anyone else run into that limit? Is there a way to raise that limit somehow? Asking nicely ;-) These limits are put in place to protect the system from overload; for people who have legitimate reasons these can be changed -- for example, for performing temporary experiments. The message to everyone -- don't let those limits stop you from doing useful measurements, talk to us and we'll see what we can do, together. Regards, Vesna From inigo at infornografia.net Thu Apr 9 17:56:16 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Thu, 9 Apr 2015 17:56:16 +0200 Subject: [atlas] list of country codes / UDM via API limit In-Reply-To: <55267919.7050907@ripe.net> References: <552545F4.9030605@afilias.info> <55267919.7050907@ripe.net> Message-ID: Hi Paul, ripe-atlas On Thu, Apr 9, 2015 at 3:05 PM, Daniel Quinn wrote: > > We don?t currently have a complete list of probes-per-country, but here?s a quick dump of what I found in our database. Note that this list includes probes currently connected, disconnected, and assumed abandoned: Another way to get a list of country codes that have active probes in them is to use the data exposed through the probe-archive API, documented here [1]. For example, the following command [2] or a similar incantation should yield a list of country codes with connected probes. HTH, I?igo [1] https://atlas.ripe.net/docs/rest/#probe-archive [2] iortiz at rigel:~ $ curl https://atlas.ripe.net/api/v1/probe-archive/?format=json | jq '[.objects[]| select(.status_name=="Connected")|.country_code]|unique' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 6280k 0 6280k 0 0 506k 0 --:--:-- 0:00:12 --:--:-- 1517k [ "AD", "AE", "AL", "AM", "AO", "AQ", "AR", "AT", "AU", "AX", "AZ", "BA", "BD", "BE", "BF", "BG", "BH", "BI", "BJ", "BL", "BR", "BT", "BW", "BY", "CA", "CH", "CL", "CM", "CN", "CO", "CR", "CU", "CW", "CY", "CZ", "DE", "DJ", "DK", "DO", "DZ", "EC", "EE", "EG", "ES", "ET", "FI", "FO", "FR", "GA", "GB", "GD", "GE", "GF", "GG", "GH", "GI", "GM", "GP", "GQ", "GR", "GT", "GU", "HK", "HN", "HR", "HU", "ID", "IE", "IL", "IM", "IN", "IQ", "IR", "IS", "IT", "JE", "JM", "JP", "KE", "KG", "KN", "KR", "KW", "KY", "KZ", "LA", "LB", "LI", "LK", "LR", "LS", "LT", "LU", "LV", "LY", "MA", "MC", "MD", "ME", "MG", "MK", "MM", "MN", "MQ", "MT", "MU", "MV", "MW", "MX", "MY", "MZ", "NA", "NC", "NE", "NG", "NI", "NL", "NO", "NP", "NZ", "PE", "PH", "PK", "PL", "PR", "PT", "PY", "QA", "RE", "RO", "RS", "RU", "RW", "SA", "SC", "SD", "SE", "SG", "SI", "SJ", "SK", "SM", "SN", "SS", "SV", "SZ", "TG", "TH", "TJ", "TN", "TO", "TR", "TT", "TW", "TZ", "UA", "UG", "US", "UY", "UZ", "VE", "VN", "VU", "WS", "ZA", "ZM", "ZW" ] -- "If you want to go fast, go alone. If you want to go far, go together." From BECHA at ripe.net Fri Apr 10 11:17:19 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 10 Apr 2015 11:17:19 +0200 Subject: [atlas] Read about the results of RIPE Atlas data visualization hackathon in the new RIPE Labs article In-Reply-To: <5527923E.2090601@ripe.net> References: <5527923E.2090601@ripe.net> Message-ID: <5527951F.1070001@ripe.net> Dear all, In March 2015, a diverse group of contributors got together to come up with creative ways to visualise the health of the Internet using RIPE Atlas open measurements data. It was the first RIPE Atlas hackathon. Impressive results were hacked together by programmers, designers and operators during an intensive weekend of work and fun in Amsterdam. In this article we celebrate hackathon achievements, document and promote hackathon results, create a memento for participants and report in detail for the benefit of the rest of the community: https://labs.ripe.net/Members/becha/ripe-atlas-hackathon-results Numbers * We received more than 70 applications for participation * Present: 24 participants & one no-show, 6 jury members and 11 support staff (coincidentally: 42!) * 6 out of 25 participants were female (24%) * 3 jury members were female (50%!) * Ten final projects were presented * Four projects were awarded prizes * 14 free & open source software projects were published on GitHub * 20 litres of tea were consumed * 10 large pizzas were eaten for lunch on Saturday * Two kilograms of chocolate Easter Eggs were munched up * 12 Club-Mate bottles were emptied Links: - All code: RIPE Atlas community pages on GitHub: https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/README.md - Videos: on RIPE NCC YouTube channel https://www.youtube.com/user/RIPENCC/videos?shelf_id=0&view=0&sort=dd - Hackathon presentations and code: https://labs.ripe.net/Members/becha/ripe-atlas-hackathon-presentations More links & photos in the article... https://labs.ripe.net/Members/becha/ripe-atlas-hackathon-results Share & Enjoy! Vesna From elane at ripe.net Mon Apr 13 14:38:26 2015 From: elane at ripe.net (Eamonn Lane) Date: Mon, 13 Apr 2015 14:38:26 +0200 Subject: [atlas] =?windows-1252?q?University_of_Ni=9A_=28RSINI=29_has_join?= =?windows-1252?q?ed_RIPE_Atlas_anchors?= Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called rs-ini-as13303 and is hosted by University of Ni? in Ni?, 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, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From pvlaar at afilias.info Mon Apr 13 23:58:51 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Mon, 13 Apr 2015 23:58:51 +0200 Subject: [atlas] negative RTT? Message-ID: <552C3C1B.5000703@afilias.info> Hi all, I noticed that one of my DNS UDMs gave back a negative RTT: {"af":4,"dst_addr":"199.19.57.1","from":"171.98.64.220","fw":4680,"group_id":1957244,"lts":39041,"msm_id":1957244,"msm_name":"Tdig","prb_id":22726,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":1,"ID":8401,"NSCOUNT":0,"QDCOUNT":1,"abuf":"INGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfkW2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACYAAwAibnMwMDBiLmFwcDI3LmlhZDEuYWZpbGlhcy1uc3QuaW5mbw==","answers":[{"MNAME":"a0.org.afilias-nst.info.","NAME":"org.","RNAME":"noc.afilias-nst.info.","SERIAL":2011454315,"TTL":900,"TYPE":"SOA"}],"rt":-14281.576,"size":133},"src_addr":"192.168.1.51","timestamp":1428948041,"type":"dns"} -14281.576ms was standing out like a sore thumb on the graph that I create out of the results from these UDMs. This is quite interesting, maybe messages from the future? :) Anyone else ran into one of these? ~paul From philip.homburg at ripe.net Tue Apr 14 10:58:34 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 14 Apr 2015 10:58:34 +0200 Subject: [atlas] negative RTT? In-Reply-To: <552C3C1B.5000703@afilias.info> References: <552C3C1B.5000703@afilias.info> Message-ID: <552CD6BA.90103@ripe.net> Hi Paul, On 2015/04/13 23:58 , Paul Vlaar wrote: > I noticed that one of my DNS UDMs gave back a negative RTT: > > {"af":4,"dst_addr":"199.19.57.1","from":"171.98.64.220","fw":4680,"group_id":1957244,"lts":39041,"msm_id":1957244,"msm_name":"Tdig","prb_id":22726,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":1,"ID":8401,"NSCOUNT":0,"QDCOUNT":1,"abuf":"INGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfkW2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACYAAwAibnMwMDBiLmFwcDI3LmlhZDEuYWZpbGlhcy1uc3QuaW5mbw==","answers":[{"MNAME":"a0.org.afilias-nst.info.","NAME":"org.","RNAME":"noc.afilias-nst.info.","SERIAL":2011454315,"TTL":900,"TYPE":"SOA"}],"rt":-14281.576,"size":133},"src_addr":"192.168.1.51","timestamp":1428948041,"type":"dns"} > > -14281.576ms was standing out like a sore thumb on the graph that I > create out of the results from these UDMs. This can be fixed by switching the measurement code to one of the alternative time sources in the Linux kernel that is not subject to these jumps. However that requires touching all time related code in the measurement code. Philip From pvlaar at afilias.info Tue Apr 14 11:05:21 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Tue, 14 Apr 2015 11:05:21 +0200 Subject: [atlas] negative RTT? In-Reply-To: <552CD6BA.90103@ripe.net> References: <552C3C1B.5000703@afilias.info> <552CD6BA.90103@ripe.net> Message-ID: <552CD851.5010303@afilias.info> On 14/4/15 10:58 AM, Philip Homburg wrote: > This can be fixed by switching the measurement code to one of the > alternative time sources in the Linux kernel that is not subject to > these jumps. However that requires touching all time related code in the > measurement code. Is there an established way to work around this on the receiving end? ~paul From robert at ripe.net Fri Apr 17 10:57:44 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 17 Apr 2015 10:57:44 +0200 Subject: [atlas] negative RTT? In-Reply-To: <552CD851.5010303@afilias.info> References: <552C3C1B.5000703@afilias.info> <552CD6BA.90103@ripe.net> <552CD851.5010303@afilias.info> Message-ID: <5530CB08.3040904@ripe.net> On 2015-04-14 11:05, Paul Vlaar wrote: > On 14/4/15 10:58 AM, Philip Homburg wrote: >> This can be fixed by switching the measurement code to one of the >> alternative time sources in the Linux kernel that is not subject to >> these jumps. However that requires touching all time related code in the >> measurement code. > > Is there an established way to work around this on the receiving end? > > ~paul RIPE Atlas is way beyond the point where you can trust *all* results blindly. Even if the measurement code and time keeping is 100% correct, there are network glitches, funny middle boxes, power brownouts, solar flares, bit flips, packet eating midgets, etc. When interpreting results, we strongly encourage users to filter out outliers (e.g. top/bottom X percentile). Regards, Robert From elane at ripe.net Fri Apr 17 11:33:53 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 17 Apr 2015 11:33:53 +0200 Subject: [atlas] NZ Registry Services, Aukland, New Zealand has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nz-lyj-as17746 and is hosted by NZ Registry Services in Aukland, New Zealand. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From elane at ripe.net Fri Apr 17 11:39:32 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 17 Apr 2015 11:39:32 +0200 Subject: [atlas] Anexia Internetdienstleistungs Gmbh, Klagenfurt, Austria has joined RIPE Atlas anchors Message-ID: <7A4038BB-E441-4AC6-97C1-EEBAB31184E5@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called at-klu-as42473 and is hosted by Anexia Internetdienstleistungs Gmbh in Klagenfurt, Austria. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From edd at theunixzoo.co.uk Fri Apr 17 12:05:43 2015 From: edd at theunixzoo.co.uk (Edd Barrett) Date: Fri, 17 Apr 2015 11:05:43 +0100 Subject: [atlas] Error when adding a measurement Message-ID: <20150417100543.GC22635@wilfred.dlink.com> Hey, A friend offered me a v3 probe, and I am currently playing around with it, exploring what I can do. I think there may be a bug in the measurements setup process. When I try to add a measurement, I get a message: "AccBalance matching query does not exist." This is not a very user friendly message. Perhaps this is suggesting that I don't have enough credit? This leads me to another potential problem. On the landing page, after I login, there is a credit summary consisting of two icons and a kind of pie chart. If I mouseover "current balance" it says 0. If I click it, the resulting page says I have 50,000 credits (the welcome bonus). I suspect that I can't setup the measurement because some part of the system thinks I have no credit. Cheers -- Best Regards Edd Barrett http://www.theunixzoo.co.uk From jterbeest at ripe.net Fri Apr 17 13:37:04 2015 From: jterbeest at ripe.net (Johan ter Beest) Date: Fri, 17 Apr 2015 13:37:04 +0200 Subject: [atlas] Accounting switch Message-ID: <5530F060.2090508@ripe.net> Dear Atlas users, We are in the middle of switching the accounting back-end. We expect this work to be finished by next week: Tuesday, April 21. There are two spots where you would be impacted: - Transferring credits Credits transferred will show up in the new system but not in the old. We have temporarily disabled the transferring of credits using the website. If you need to have some credits transferred urgently, you can email us at atlas-dev at ripe.net and we will make the transfer for you - When you register a new probe and are a first time probe host (ie, you have no credits at all) The 50.000 credits welcome bonus is applied to the new system while the measurements scheduling checks the old system resulting in an error. This is a fairly rare scenario as most of our hosts have credits already. When we spot this, we will contact the host and adjust his credits manually. There will be no danger of losing credits or measurements being stopped accidentally as a result of this switch. Thank you for your patience while we make this switch. Kind regards, Johan ter Beest RIPE Atlas Team From parry.jacob at gmail.com Fri Apr 17 15:41:06 2015 From: parry.jacob at gmail.com (Jacob Parry) Date: Fri, 17 Apr 2015 13:41:06 +0000 Subject: [atlas] Error when adding a measurement In-Reply-To: <20150417100543.GC22635@wilfred.dlink.com> References: <20150417100543.GC22635@wilfred.dlink.com> Message-ID: I believe this was brought up earlier in this list. RIPE is currently doing some work on switching the accounting system over, so there may be some discrepancies for a while as everything is switched over. Regards, Jacob Parry On Fri, Apr 17, 2015 at 6:12 AM Edd Barrett wrote: > Hey, > > A friend offered me a v3 probe, and I am currently playing around with > it, exploring what I can do. > > I think there may be a bug in the measurements setup process. When I try > to add a measurement, I get a message: > > "AccBalance matching query does not exist." > > This is not a very user friendly message. Perhaps this is suggesting that > I > don't have enough credit? This leads me to another potential problem. > > On the landing page, after I login, there is a credit summary consisting of > two icons and a kind of pie chart. If I mouseover "current balance" it says > 0. If I click it, the resulting page says I have 50,000 credits (the > welcome bonus). > > I suspect that I can't setup the measurement because some part of the > system thinks I have no credit. > > Cheers > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Apr 20 11:28:42 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 20 Apr 2015 11:28:42 +0200 Subject: [atlas] RIPE Atlas accounting system renewal Message-ID: <5534C6CA.5030609@ripe.net> Dear Users, Today we're renewing our internal accounting system in RIPE Atlas. This change is almost exclusively internal, it hardly shows up on the public pages. If you see discrepancies regarding your credits tomorrow, then please let us know at atlas at ripe.net (ie. NOT this mailing list) so we can check. We'll privately contact the few users where we expect a more visible change. Regards, Robert & Johan & the rest of the team From bjorn at mork.no Tue Apr 21 09:12:12 2015 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 21 Apr 2015 09:12:12 +0200 Subject: [atlas] IPv6 auto-tagging failure? Message-ID: <87pp6yosz7.fsf@nemi.mork.no> Hello, I'm wondering a bit about the IPv6 auto-tagging. I recently reveived a v3 probe and connected it to a dual-stack enabled network. The probe was initially tagged as 2015-04-16 20:23 UTC Probe auto-tagged Your probe #22894 was automatically tagged as "system: IPv6 Capable" but then (on the next batch run?, after a couple of quick firmware upgrades (3.3.8 => 4650 => 4680): 2015-04-17 08:23 UTC Probe auto-untagged Your probe #22894 was automatically untagged as "system: IPv6 Capable" and there it has been since. This wouldn't worry me too much if it otherwise worked, but I noticed that the probe isn't listed with an "ASN v6" either. So I assume the missing tag prevents it from being used for v6 probing? AFAICS, the probe does take the announced prefix, and is actually *using* the provided IPv6 connectivity. The "Connection History" shows that it consistently uses its SLAAC address to connect to the controller. So why isn't it tagged as IPv6 capable/works etc? In desperation I tried different netwrok settings, static address, adding v6 DNS, and fiddling with the managed/other flags along with matching DHCPv6 config. Made no difference of course. If I understood correctly, the probe firmware won't currently do any DHCPv6, and v6 DNS is optional as long as there is a working v4 resolver available. Bj?rn From daniel.karrenberg at ripe.net Tue Apr 21 11:04:03 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 21 Apr 2015 11:04:03 +0200 Subject: [atlas] IPv6 auto-tagging failure? In-Reply-To: <87pp6yosz7.fsf@nemi.mork.no> References: <87pp6yosz7.fsf@nemi.mork.no> Message-ID: <55361283.10500@ripe.net> On 21.04.15 9:12 , Bj?rn Mork wrote: > Hello, > > I'm wondering a bit about the IPv6 auto-tagging. I recently reveived a > v3 probe and connected it to a dual-stack enabled network. The probe > was initially tagged as > > 2015-04-16 20:23 UTC Probe auto-tagged Your probe #22894 was automatically tagged as "system: IPv6 Capable" > > but then (on the next batch run?, after a couple of quick firmware > upgrades (3.3.8 => 4650 => 4680): > > 2015-04-17 08:23 UTC Probe auto-untagged Your probe #22894 was automatically untagged as "system: IPv6 Capable" > > and there it has been since. This wouldn't worry me too much if it > otherwise worked, but I noticed that the probe isn't listed with an "ASN > v6" either. So I assume the missing tag prevents it from being used for > v6 probing? > > AFAICS, the probe does take the announced prefix, and is actually *using* > the provided IPv6 connectivity. The "Connection History" shows that it > consistently uses its SLAAC address to connect to the controller. > > So why isn't it tagged as IPv6 capable/works etc? > > In desperation I tried different netwrok settings, static address, > adding v6 DNS, and fiddling with the managed/other flags along with > matching DHCPv6 config. Made no difference of course. If I understood > correctly, the probe firmware won't currently do any DHCPv6, and v6 DNS > is optional as long as there is a working v4 resolver available. > > > Bj?rn I have had similar seemingly illogical automagic tagging actions on my probes #7 and #8. Daniel From camin at ripe.net Tue Apr 21 11:33:47 2015 From: camin at ripe.net (Chris Amin) Date: Tue, 21 Apr 2015 11:33:47 +0200 Subject: [atlas] IPv6 auto-tagging failure? In-Reply-To: <87pp6yosz7.fsf@nemi.mork.no> References: <87pp6yosz7.fsf@nemi.mork.no> Message-ID: <5536197B.6000704@ripe.net> Dear Bj?rn, This was caused by an issue with the particular controller that your probe was connected to. This issue affected 30 probes in total, and prevented their IPv6 capability from being properly detected. The problem has now been fixed, and you can see that your probe is now tagged as "IPv6 Capable". Within a few hours it will also be tagged as "IPv6 Works" as long as it carries out successful IPv6 measurement results. Sorry for the inconvenience, and thanks for pointing this out! Regards, Chris Amin RIPE NCC Developer On 21/04/2015 09:12, Bj?rn Mork wrote: > Hello, > > I'm wondering a bit about the IPv6 auto-tagging. I recently reveived a > v3 probe and connected it to a dual-stack enabled network. The probe > was initially tagged as > > 2015-04-16 20:23 UTC Probe auto-tagged Your probe #22894 was automatically tagged as "system: IPv6 Capable" > > but then (on the next batch run?, after a couple of quick firmware > upgrades (3.3.8 => 4650 => 4680): > > 2015-04-17 08:23 UTC Probe auto-untagged Your probe #22894 was automatically untagged as "system: IPv6 Capable" > > and there it has been since. This wouldn't worry me too much if it > otherwise worked, but I noticed that the probe isn't listed with an "ASN > v6" either. So I assume the missing tag prevents it from being used for > v6 probing? > > AFAICS, the probe does take the announced prefix, and is actually *using* > the provided IPv6 connectivity. The "Connection History" shows that it > consistently uses its SLAAC address to connect to the controller. > > So why isn't it tagged as IPv6 capable/works etc? > > In desperation I tried different netwrok settings, static address, > adding v6 DNS, and fiddling with the managed/other flags along with > matching DHCPv6 config. Made no difference of course. If I understood > correctly, the probe firmware won't currently do any DHCPv6, and v6 DNS > is optional as long as there is a working v4 resolver available. > > > Bj?rn > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2713 bytes Desc: S/MIME Cryptographic Signature URL: From BECHA at ripe.net Fri Apr 24 12:25:55 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 24 Apr 2015 12:25:55 +0200 Subject: [atlas] New on RIPE Labs: Measuring Countries and IXPs in the SEE Region In-Reply-To: <553A1239.80806@ripe.net> References: <553A1239.80806@ripe.net> Message-ID: <553A1A33.4040005@ripe.net> Dear all, In this post we look at 10 countries in South East Europe and see how we can use RIPE Atlas to get a sense of routing and the interconnectedness of networks in these countries: https://labs.ripe.net/Members/emileaben/measuring-countries-and-ixps-in-the-see-region Two prototype tools used here can benefit from your feedback & involvement: IXP-Jedi & OpenIPMap. Please take some time to play with the interactive grid (IXP-Jedi), e.g. for Romania: http://sg-pub.ripe.net/emile/ixp-country-jedi/RO-2015-04/ixpcountry/ Code: https://github.com/emileaben/ixp-country-jedi/ Or join the OpenIPMap to crowdsource geolocation of IP infrastructure: https://github.com/RIPE-Atlas-Community/openipmap Kind regards, Vesna From graham at apolix.co.za Tue Apr 28 11:17:57 2015 From: graham at apolix.co.za (Graham Beneke) Date: Tue, 28 Apr 2015 11:17:57 +0200 Subject: [atlas] Geographic Selection of Probe Message-ID: <553F5045.2010906@apolix.co.za> Hi All Due to the huge number of probes in Europe there is always a heavy bias when selecting "whole world" for UDMs. In the past I could get around this by requesting numbers of probes from each region/continent. I can't figure out how to do this on the new interface. Using the wizard there does not seem to be a way to request a random subset of probes within the area selected. When using the manual probe selection I can't find what area codes I can use besides "WW" Am I missing something? -- Graham Beneke graham at apolix.co.za From mcandela at ripe.net Tue Apr 28 12:32:00 2015 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 28 Apr 2015 12:32:00 +0200 Subject: [atlas] Geographic Selection of Probe In-Reply-To: <553F5045.2010906@apolix.co.za> References: <553F5045.2010906@apolix.co.za> Message-ID: Hello Graham, On 28 Apr 2015, at 11:17, Graham Beneke wrote: > Hi All > > Due to the huge number of probes in Europe there is always a heavy bias > when selecting "whole world" for UDMs. In the past I could get around > this by requesting numbers of probes from each region/continent. I can't > figure out how to do this on the new interface. > > Using the wizard there does not seem to be a way to request a random > subset of probes within the area selected. No, it is possible only at country level in the wizard. > When using the manual probe > selection I can't find what area codes I can use besides ?WW" Sorry, that feature was re-enabled recently, and the auto-suggestion for the ?area? selection it is not deployed yet. But it works and the values are the same of the API, documented here: https://atlas.ripe.net/docs/measurement-creation-api/ (under Probes/area) Thank you for the feedback, we will work to make it more clear and easy. If you have any other question, please don?t hesitate to contact me. Best regards, Massimo Candela > > Am I missing something? > > -- > Graham Beneke > graham at apolix.co.za > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: