From mcandela at ripe.net Wed Jul 1 10:59:24 2015 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 1 Jul 2015 10:59:24 +0200 Subject: [atlas] RIPE Atlas traceroute visualisation - use cases Message-ID: <7A31DDBE-3505-487E-AA34-7FC0A0F51FB5@ripe.net> Hello, We are creating a tool to visualise traceroute results coming from the RIPE Atlas measurement network. The tool will of course be available to everyone. To help make this tool as useful as possible, I?m gathering use cases of day-to-day operations and research activities that use traceroute measurements. I hope you can spend a few minutes to answer this email and tell me how you use traceroute measurements or what you would like to have in such a tool. For each use case you have in mind, please describe it briefly. Keep in mind our system can collect measurements from multiple sources to a single target repeatedly (e.g. every 60 seconds). Don?t focus only on traceroute data, but also on correlations among traceroutes and BGP, RTT, geolocations, DNS, and registry information (feel free to expand the list to other datasets). Thanks for your time. Your help is invaluable. Ciao, Massimo RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From bortzmeyer at nic.fr Wed Jul 1 15:47:59 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 1 Jul 2015 15:47:59 +0200 Subject: [atlas] RIPE Atlas traceroute visualisation - use cases In-Reply-To: <7A31DDBE-3505-487E-AA34-7FC0A0F51FB5@ripe.net> References: <7A31DDBE-3505-487E-AA34-7FC0A0F51FB5@ripe.net> Message-ID: <20150701134759.GA19275@nic.fr> On Wed, Jul 01, 2015 at 10:59:24AM +0200, Massimo Candela wrote a message of 86 lines which said: > I hope you can spend a few minutes to answer this email and tell me > how you use traceroute measurements or what you would like to have > in such a tool. For each use case you have in mind, please describe > it briefly. Well, my usage is simple: when I run a test (DNS, ping) and a few of the probes fail or give an unexpected result, I run a traceroute from these probes to try to find out why they failed. I use a modified version of (I should commit it, one day) and From robert at ripe.net Thu Jul 2 09:35:32 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 02 Jul 2015 09:35:32 +0200 Subject: [atlas] Probe and measurement archives vs. the APIs Message-ID: <5594E9C4.5030504@ripe.net> Dear All, We've observed recently that some users are using scripts to "crawl" through all the metadata provided by the probe and measurement APIs. This means that some people out there download basically the entire probe and/or measurement meta data set the system provides. As you can imagine, this is highly inefficient and keeps our servers busy. We believe that there could be better solutions. We have been providing the downloadable archive for probe metadata for some time now, and recently we've added the measurement metadata too. You can now reach these at http://ftp.ripe.net/ripe/atlas/ This way one can even get complete sets of metadata as far back as January 2015 for measurement specifications and March 2014 for probe data. Given the existence of these archives, we will apply a sane limit on how much metadata can be reached via the APIs. In practice this means that the API will not allow fetching results beyond, say, 10.000 (i.e. 500 pages of 20) entries. This is after the application of filters, so for example with no filters at all you could still access metadata of the 10k newest measurements, while if you filter for DNS measurements only, you could get the 10k newest of those, and so on. We believe this keeps the metadata API useful for the majority of the users, while the existence of the archive serves the remaining cases. Our plan is to make this change around the end of July. Regards, Robert Kisteleki From robert at ripe.net Thu Jul 2 12:57:49 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 02 Jul 2015 12:57:49 +0200 Subject: [atlas] Fwd: [mat-wg] New on RIPE Labs: Improving RIPE Atlas Coverage. What Networks are Missing? In-Reply-To: <5595100F.50204@ripe.net> References: <5595100F.50204@ripe.net> Message-ID: <5595192D.9050207@ripe.net> Dear all, The following article might be of interest to you. Regards, Robert -------- Forwarded Message -------- Subject: [mat-wg] New on RIPE Labs: Improving RIPE Atlas Coverage. What Networks are Missing? Date: Thu, 02 Jul 2015 12:18:55 +0200 From: Mirjam Kuehne To: mat-wg at ripe.net Dear colleagues, In this article we compare RIPE Atlas deployment against user population estimates provided by APNIC to see what eyeball networks are missing out on RIPE Atlas probes: https://labs.ripe.net/Members/emileaben/improving-ripe-atlas-coverage-what-networks-are-missing Kind regards, Mirjam Kuehne RIPE NCC From bortzmeyer at nic.fr Sun Jul 5 15:56:08 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 5 Jul 2015 15:56:08 +0200 Subject: [atlas] Wrong IP prefix values accepted? In-Reply-To: <550868DE.9020309@ripe.net> References: <20150317151508.GA11604@nic.fr> <550868DE.9020309@ripe.net> Message-ID: <20150705135607.GA23760@nic.fr> On Tue, Mar 17, 2015 at 06:48:14PM +0100, Daniel Quinn wrote a message of 14 lines which said: > Unfortunately, the issue of rejecting should-be-valid prefixes was > not as simple a problem and that's going to take a little longer to > fix. We have a few people tasked now with fixing this. It's a > known problem with how we handle comparing IPs to prefixes in our > database and we hope to have that working in production tomorrow as > well -- though it may take a smidge longer than that. Apparently, it is not yet fixed? For: {'definitions': [{'target': '2001:4b98:dc2:45:216:3eff:fe4b:8c5b', 'af': 6, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'description': 'Ping 2001:4b98:dc2:45:216:3eff:fe4b:8c5b from prefix 2000::/3'}], 'probes': [{'requested': 10, 'type': 'prefix', 'value': '2000::/3'}]} I get: Status 400, reason "{"error":{"message":"__all__: Your selected prefix is not covered by our network.","code":104}}" But 2000::/3 is the entire IPv6 space currently allocated, all the Atlas probes are certainly in it. From bortzmeyer at nic.fr Sun Jul 5 18:10:33 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 5 Jul 2015 18:10:33 +0200 Subject: [atlas] API to get information about a probe? Message-ID: <20150705161033.GA27588@sources.org> I cannot find an API to retrieve information about a probe. I would like to get the information I can see on, for instance, but from a REST + JSON API. Does it exist? Do you think it would be a nice addition? (My current use case is that I find some probes failing to ping a target and I would like to quickly check if they share something, such as ASn or some tags.) From vnaumov at ripe.net Sun Jul 5 21:34:40 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Sun, 05 Jul 2015 21:34:40 +0200 Subject: [atlas] API to get information about a probe? In-Reply-To: <20150705161033.GA27588@sources.org> References: <20150705161033.GA27588@sources.org> Message-ID: <559986D0.2010601@ripe.net> Hi Stephane, Here you go: Docs: https://atlas.ripe.net/docs/rest/#probe How to get current probe status: https://atlas.ripe.net/api/v1/probe/10644/ How to get archived probe status for a given day: https://atlas.ripe.net/api/v1/probe-archive/10644/?format=json&day=20150606 Cheers! /vty On 7/5/15 6:10 PM, Stephane Bortzmeyer wrote: > I cannot find an API to retrieve information about a probe. I would > like to get the information I can see on, for instance, > but from a REST + JSON > API. Does it exist? Do you think it would be a nice addition? > > (My current use case is that I find some probes failing to ping a > target and I would like to quickly check if they share something, such > as ASn or some tags.) > > From bortzmeyer at nic.fr Sun Jul 5 23:31:40 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 5 Jul 2015 23:31:40 +0200 Subject: [atlas] API to get information about a probe? In-Reply-To: <559986D0.2010601@ripe.net> References: <20150705161033.GA27588@sources.org> <559986D0.2010601@ripe.net> Message-ID: <20150705213140.GA30282@sources.org> On Sun, Jul 05, 2015 at 09:34:40PM +0200, Viktor Naumov wrote a message of 26 lines which said: > Here you go: > Docs: https://atlas.ripe.net/docs/rest/#probe Thanks, it works. Some fields are missing such as architecture (v1, v2, v3...) or DNS resolvers. {"prefix_v4": "81.220.128.0/17", "status": 1, "prefix_v6": null, "is_anchor": false, "tags": ["system-v3", "system-resolver-mangles-case", "system-ipv4-works", "system-ipv4-capable", "system-ipv4-rfc1918"], "status_name": "Connected", "address_v6": null, "longitude": 5.7005, "address_v4": "81.220.164.242", "country_code": "FR", "is_public": true, "latitude": 45.1895, "asn_v4": 21502, "asn_v6": null, "status_since": 1435042368, "id": 22874} From vnaumov at ripe.net Mon Jul 6 08:14:19 2015 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 06 Jul 2015 08:14:19 +0200 Subject: [atlas] API to get information about a probe? In-Reply-To: <20150705213140.GA30282@sources.org> References: <20150705161033.GA27588@sources.org> <559986D0.2010601@ripe.net> <20150705213140.GA30282@sources.org> Message-ID: <559A1CBB.4020900@ripe.net> DNS resolvers are not displayed, but architecture is. "system-v3" is the tag representing probe v3 /vty On 7/5/15 11:31 PM, Stephane Bortzmeyer wrote: > On Sun, Jul 05, 2015 at 09:34:40PM +0200, > Viktor Naumov wrote > a message of 26 lines which said: > >> Here you go: >> Docs: https://atlas.ripe.net/docs/rest/#probe > Thanks, it works. > > Some fields are missing such as architecture (v1, v2, v3...) or DNS > resolvers. > > {"prefix_v4": "81.220.128.0/17", "status": 1, "prefix_v6": null, "is_anchor": false, "tags": ["system-v3", "system-resolver-mangles-case", "system-ipv4-works", "system-ipv4-capable", "system-ipv4-rfc1918"], "status_name": "Connected", "address_v6": null, "longitude": 5.7005, "address_v4": "81.220.164.242", "country_code": "FR", "is_public": true, "latitude": 45.1895, "asn_v4": 21502, "asn_v6": null, "status_since": 1435042368, "id": 22874} > From jon.brewer at gmail.com Tue Jul 7 01:34:22 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Tue, 7 Jul 2015 07:34:22 +0800 Subject: [atlas] Fwd: Your RIPE Atlas Probe (ID: 22769) is not connected to our network In-Reply-To: <20150705234040.30490.90960@janus.atlas.ripe.net> References: <20150705234040.30490.90960@janus.atlas.ripe.net> Message-ID: Hi There, My probe 22769 appears to be malfunctioning, and I'm not sure what to do in terms of diagnostics. >From the router nearest it on the network: https://www.dropbox.com/s/ghe4e3tz69u1kvc/Screenshot%202015-07-07%2011.30.10.png?dl=0 Looks to me as if it's rebooting frequently, but I have no way to check without an in-person visit. Do you have any suggestions as to how to troubleshoot? I have access to the network it's on. Thanks, Jon ---------- Forwarded message ---------- From: RIPE Atlas Date: 6 July 2015 at 07:40 Subject: Your RIPE Atlas Probe (ID: 22769) is not connected to our network To: jon.brewer at gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! We have noticed that your probe (#22769 with description MDC) is not connected to our infrastructure and has been disconnected since 2015-06-28 22:42 UTC. Could you please check whether everything is set up correctly on your side? If it is, and your probe is still reported as disconnected when you log in at https://atlas.ripe.net, please reply to this email so that we can follow up. You can review the instructions for setting up your probe at https://atlas.ripe.net/getting-started If you have any questions, please contact us at atlas at ripe.net Best regards, RIPE Atlas Team ********** You are receiving this message because you applied for or were given a RIPE Atlas probe. We will only send messages when your probe becomes disconnected for an extended period of time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pekka.jarvinen at gmail.com Mon Jul 6 23:24:10 2015 From: pekka.jarvinen at gmail.com (=?UTF-8?Q?Pekka_J=C3=A4rvinen?=) Date: Tue, 7 Jul 2015 00:24:10 +0300 Subject: [atlas] LLDP / LLDP-MED support? Message-ID: Hi, Would there be any idea to add LLDP support to probes? -- Pekka J?rvinen -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Jul 7 11:05:34 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 7 Jul 2015 11:05:34 +0200 Subject: [atlas] LLDP / LLDP-MED support? In-Reply-To: References: Message-ID: <559B965E.4080101@ripe.net> Hi Pekka, It is not clear what you want out of LLDP. RIPE Atlas probes should minimize the amount of data they collect about the local network. So most of LLDP seems irrelevant to probes. There is also something about VLANs. But I prefer to keep probes on untagged ethernets. Network configuration of probes is already complex enough as it is. Philip From dragonn at email.cz Tue Jul 7 14:41:45 2015 From: dragonn at email.cz (Mirek Kalina) Date: Tue, 07 Jul 2015 14:41:45 +0200 Subject: [atlas] LLDP / LLDP-MED support? In-Reply-To: <559B965E.4080101@ripe.net> References: <559B965E.4080101@ripe.net> Message-ID: <559BC909.1050905@email.cz> Hi there, I am not original requestor, but I think it could be helpful for someone when you can see Probe from your router/switch via LLDP. I don't see any purpose of collecting LLDP informations by probe itself. Only configuration related thing could be whether to enable (Y/N) and use also CDR/NDP/... Mirek On 07/07/2015 11:05 AM, Philip Homburg wrote: > Hi Pekka, > > It is not clear what you want out of LLDP. RIPE Atlas probes should > minimize the amount of data they collect about the local network. So > most of LLDP seems irrelevant to probes. > > There is also something about VLANs. But I prefer to keep probes on > untagged ethernets. Network configuration of probes is already complex > enough as it is. > > Philip > From bortzmeyer at nic.fr Tue Jul 7 16:56:42 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 7 Jul 2015 16:56:42 +0200 Subject: [atlas] Get the list of all probes? Message-ID: <20150707145642.GA11163@nic.fr> For a project (testing the randomness of probe selection), I need a list of all probes. The only solution I find is a loop over Is there a simpler way? seems to say there is a JSON file with all probes but it yields a 404 (reported to the RIPE-NCC, ticket [ripe.net #1179513]) From robert at ripe.net Tue Jul 7 17:01:48 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 07 Jul 2015 17:01:48 +0200 Subject: [atlas] Get the list of all probes? In-Reply-To: <20150707145642.GA11163@nic.fr> References: <20150707145642.GA11163@nic.fr> Message-ID: <559BE9DC.3050801@ripe.net> On 2015-07-07 16:56, Stephane Bortzmeyer wrote: > For a project (testing the randomness of probe selection), I need a > list of all probes. > > The only solution I find is a loop over > > > Is there a simpler way? > seems to say > there is a JSON file with all probes but it yields a 404 (reported to > the RIPE-NCC, ticket [ripe.net #1179513]) Hi, Quoting from a mail from last week: > We have been providing the downloadable archive for probe metadata for some > time now, and recently we've added the measurement metadata too. You can now > reach these at http://ftp.ripe.net/ripe/atlas/ Cheers, Robert From bortzmeyer at nic.fr Tue Jul 7 17:11:31 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 7 Jul 2015 17:11:31 +0200 Subject: [atlas] Get the list of all probes? In-Reply-To: <559BE9DC.3050801@ripe.net> References: <20150707145642.GA11163@nic.fr> <559BE9DC.3050801@ripe.net> Message-ID: <20150707151131.GA12962@nic.fr> On Tue, Jul 07, 2015 at 05:01:48PM +0200, Robert Kisteleki wrote a message of 22 lines which said: > We have been providing the downloadable archive for probe metadata > for some time now, and recently we've added the measurement metadata > too. You can now reach these at http://ftp.ripe.net/ripe/atlas/ Perfect, it works. One last thing: what about a symbolic link, "current", going to the latest file, to ease automation? From robert at ripe.net Tue Jul 7 17:14:33 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 07 Jul 2015 17:14:33 +0200 Subject: [atlas] Get the list of all probes? In-Reply-To: <20150707151131.GA12962@nic.fr> References: <20150707145642.GA11163@nic.fr> <559BE9DC.3050801@ripe.net> <20150707151131.GA12962@nic.fr> Message-ID: <559BECD9.7060202@ripe.net> On 2015-07-07 17:11, Stephane Bortzmeyer wrote: > On Tue, Jul 07, 2015 at 05:01:48PM +0200, > Robert Kisteleki wrote > a message of 22 lines which said: > >> We have been providing the downloadable archive for probe metadata >> for some time now, and recently we've added the measurement metadata >> too. You can now reach these at http://ftp.ripe.net/ripe/atlas/ > > Perfect, it works. One last thing: what about a symbolic link, > "current", going to the latest file, to ease automation? Yes, it's a nice convention, we'll add that too. Cheers, Robert From philip.homburg at ripe.net Tue Jul 7 17:29:55 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 7 Jul 2015 17:29:55 +0200 Subject: [atlas] Upcoming change to DNS IN/TXT query result Message-ID: <559BF073.6020107@ripe.net> Hi, This is to inform you about a change in a future release of the RIPE Atlas firmware that changes how 'IN TXT' records get decoded in DNS measurements. Currently, the JSON generated by the probe for TXT query looks like this: { "fw" : -1 , "time" : 1436282373 , "lts" : -1 , "name" : "stereo.hq.phicoh.net" , "dst_addr" : "130.37.15.35" , "af" : 4 , "src_addr" : "193.0.10.226" , "proto" : "UDP" ,"result" : { "rt" : 12.172,"size" : 219 , "ID" : 45298 , "ANCOUNT" : 1 , "QDCOUNT" : 1 , "NSCOUNT" : 2 , "ARCOUNT" : 2,"abuf" : "sPKEAAABAAEAAgACB2RyYWdvbnMEYWlveQJldQAAEAABB2RyYWdvbnMEYWlveQJldQAAEAABAAAOEABPJUhlcmUgYmUg/yBkcmFnb25zISBXaXRoIFwgYW5kICIgYW5kIH8IYXMgd2VsbC4fVGhyb3dpbmcgaW4ggCBmb3IgZ29vZCBtZWFzdXJlLsApAAIAAQAADhAABgNuczHAKcApAAIAAQAADhAABgNuczLAKcCXAAEAAQAADhAABIIlDyPAqQAcAAEAAA4QABAgAQRw0WoAEAKgyf/+nxep","answers" : [ {"TYPE" : "TXT" , "NAME" : "dragons.aioy.eu" , "RDATA" : "Here be \u00FF dragons! With \\ and \" and \u0008as well.\u001FThrowing in \u0080 for good measure."} ] } } Note that the '\u' escape sequence is used escape characters outside the safe ASCII range and that the code fails to support more than one string (the actual reply contains 3 strings). The '\u' notation seemed like a good idea at the time, but because it is valid JSON it is not always transparent and it triggered bugs in other software. The plan is to move to the following format: { "fw" : -1 , "time" : 1436282575 , "lts" : -1 , "name" : "stereo.hq.phicoh.net" , "dst_addr" : "130.37.15.35" , "af" : 4 , "src_addr" : "193.0.10.226" , "proto" : "UDP" ,"result" : { "rt" : 13.186,"size" : 219 , "ID" : 45298 , "ANCOUNT" : 1 , "QDCOUNT" : 1 , "NSCOUNT" : 2 , "ARCOUNT" : 2,"abuf" : "sPKEAAABAAEAAgACB2RyYWdvbnMEYWlveQJldQAAEAABB2RyYWdvbnMEYWlveQJldQAAEAABAAAOEABPJUhlcmUgYmUg/yBkcmFnb25zISBXaXRoIFwgYW5kICIgYW5kIH8IYXMgd2VsbC4fVGhyb3dpbmcgaW4ggCBmb3IgZ29vZCBtZWFzdXJlLsApAAIAAQAADhAABgNuczHAKcApAAIAAQAADhAABgNuczLAKcCXAAEAAQAADhAABIIlDyPAqQAcAAEAAA4QABAgAQRw0WoAEAKgyf/+nxep","answers" : [ {"TYPE" : "TXT" , "NAME" : "dragons.aioy.eu" , "RDATA" : [ "Here be \\255 dragons! With \\092 and \\034 and \\127", "as well.", "Throwing in \\128 for good measure." ] } ] } } Here the escape sequence is similar to the one in DNS zone files. Except that the backslash has to be doubled in JSON. Furthermore, after RDATA comes a list of strings instead of a single string directly. For anyone who parses the JSON output directly, the change from a single string to a list of strings is probably the biggest change. Similar changes will be made in the Sagan package. There, python tricks may hide the list if the result is used in a string context. Philip From proskurnin at legioncom.ru Wed Jul 8 11:17:46 2015 From: proskurnin at legioncom.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGA?=) Date: Wed, 8 Jul 2015 12:17:46 +0300 Subject: [atlas] unable to delete measurements Message-ID: <559CEABA.1050801@legioncom.ru> Hi devs! I just created a few measurements through web browser and now I can't stop them (red button). In the browser debug I see server response after i click on the button is 403 Forbidden. Measurement ids: 2072826 , 2072825 , 2072816 . -- Best regads, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Wed Jul 8 11:41:08 2015 From: camin at ripe.net (Chris Amin) Date: Wed, 08 Jul 2015 11:41:08 +0200 Subject: [atlas] unable to delete measurements In-Reply-To: <559CEABA.1050801@legioncom.ru> References: <559CEABA.1050801@legioncom.ru> Message-ID: <559CF034.1020208@ripe.net> Hi Alexander, Thanks for this report. We have heard similar problems from other users and we are currently working on a priority fix for this issue. Regards, Chris Amin RIPE NCC On 08/07/2015 11:17, ????????? wrote: > Hi devs! > > I just created a few measurements through web browser and now I can't > stop them (red button). > In the browser debug I see server response after i click on the button > is 403 Forbidden. > Measurement ids: 2072826 , > 2072825 , 2072816 > . > > > From camin at ripe.net Wed Jul 8 13:46:40 2015 From: camin at ripe.net (Chris Amin) Date: Wed, 08 Jul 2015 13:46:40 +0200 Subject: [atlas] unable to delete measurements In-Reply-To: <559CF034.1020208@ripe.net> References: <559CEABA.1050801@legioncom.ru> <559CF034.1020208@ripe.net> Message-ID: <559D0DA0.6050708@ripe.net> This issue has now been resolved. Please let me know if you have any more problems. Regards, Chris On 08/07/2015 11:41, Chris Amin wrote: > Hi Alexander, > > Thanks for this report. We have heard similar problems from other users > and we are currently working on a priority fix for this issue. > > Regards, > Chris Amin > RIPE NCC > > On 08/07/2015 11:17, ????????? wrote: >> Hi devs! >> >> I just created a few measurements through web browser and now I can't >> stop them (red button). >> In the browser debug I see server response after i click on the button >> is 403 Forbidden. >> Measurement ids: 2072826 , >> 2072825 , 2072816 >> . >> >> >> > > From elvertoncf at gmail.com Tue Jul 14 17:06:14 2015 From: elvertoncf at gmail.com (Elverton Fazzion) Date: Tue, 14 Jul 2015 12:06:14 -0300 Subject: [atlas] Problem in stopping measuraments Message-ID: Hello, I've got a issue trying to stop a measurament. I used the RIPE normally last year and I started to use it again two weeks ago. I realized that one experiment was still running since last year and I tried to stop it by using the REST API as described in the documentation. Unfortunately, it did not work. Thus, I tried to stop in the web interface and it did not work either. I do not know how to proceed in order to stop it. The credits got negative even I denied this kind of situation in my profile. Anyone had the same problem? The measurament ID of my experiment is 1791052. Thank you, Elverton. -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Tue Jul 14 17:31:32 2015 From: camin at ripe.net (camin) Date: Tue, 14 Jul 2015 17:31:32 +0200 Subject: [atlas] Problem in stopping measuraments In-Reply-To: References: Message-ID: Hi Elverton, I can unfortunately not replicate this bug. There was a problem with stopping measurements last week, but that should have been fixed. Can you confirm that it is still not working using either the UI or the API? Could you send me a private e-mail containing the URL and API key that you are using in the REST API call? Many thanks, Chris Amin RIPE NCC On 2015-07-14 17:06, Elverton Fazzion wrote: > Hello, > > I've got a issue trying to stop a measurament. I used the RIPE > normally last year and I started > to use it again two weeks ago. I realized that one experiment was > still running since last year > and I tried to stop it by using the REST API as described in the > documentation. Unfortunately, it did > > not work. Thus, I tried to stop in the web interface and it did not > work either. > > I do not know how to proceed in order to stop it. The credits got > negative even I denied this kind of situation in my profile. > > Anyone had the same problem? > > The measurament ID of my experiment is 1791052. > > Thank you, > > Elverton. From yang.yu.list at gmail.com Thu Jul 16 01:23:20 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Thu, 16 Jul 2015 08:23:20 +0900 Subject: [atlas] atlas.ripe.net site 302 redirect loop Message-ID: I have been having this issue with every feature that requires logging in on https://atlas.ripe.net. For instance, when I try to create an API key, HTTP POST to /keys/create/ gets a 302 to https://atlas.ripe.net/login?next=/keys/create/, then the new GET results in another 302 to https://atlas.ripe.net/keys/create/ and back to https://atlas.ripe.net/login?next=/keys/create/ until the browser gives up on redirecting and throws an error. Tested on Chrome/Firefox with Ubuntu trusty and Windows 7. Tried on a different computer from a different continent, still the same issue. From mgalante at ripe.net Thu Jul 16 17:19:13 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 16 Jul 2015 17:19:13 +0200 Subject: [atlas] BDIX (Bangladesh) has joined RIPE Atlas anchors Message-ID: <23291F1A-A529-4621-9762-B73BFA449A05@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 bd-dac-as24122 and it is hosted by BDIX in Dhaka, Bangladesh, and sponsored by APNIC. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From robert at ripe.net Mon Jul 20 15:39:55 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 20 Jul 2015 15:39:55 +0200 Subject: [atlas] atlas.ripe.net site 302 redirect loop In-Reply-To: References: Message-ID: <55ACFA2B.1060006@ripe.net> On 2015-07-16 1:23, Yang Yu wrote: > I have been having this issue with every feature that requires logging > in on https://atlas.ripe.net. > > For instance, when I try to create an API key, HTTP POST to > /keys/create/ gets a 302 to > https://atlas.ripe.net/login?next=/keys/create/, then the new GET > results in another 302 to https://atlas.ripe.net/keys/create/ and back > to https://atlas.ripe.net/login?next=/keys/create/ until the browser > gives up on redirecting and throws an error. > > Tested on Chrome/Firefox with Ubuntu trusty and Windows 7. Tried on a > different computer from a different continent, still the same issue. Dear All, We've heard others reporting this issue as well. We have been, and still are looking into it. We can confirm that the issue is real, but it proves difficult to track down the root cause. We'll report back with our findings, and hopefully a solution too, shortly. Regards, Robert Kisteleki, for the RIPE Atlas team From camin at ripe.net Mon Jul 20 17:26:04 2015 From: camin at ripe.net (camin) Date: Mon, 20 Jul 2015 17:26:04 +0200 Subject: [atlas] atlas.ripe.net site 302 redirect loop In-Reply-To: <55ACFA2B.1060006@ripe.net> References: <55ACFA2B.1060006@ripe.net> Message-ID: <8b8f1d515d2309870544ada7085bd314@ripe.net> Dear all, We have found the cause of and fixed this issue, so it should now be resolved for all affected users. The problem was an obscure bug affecting up to 2.5% of active users by preventing proper login session persistence. It was caused by a security enhancement present in a web framework upgrade carried out earlier this year interacting with the RIPE Access single sign-on service. Apologies to all affected users. If you believe that you are still experiencing this (or any other) issue, please do not hesitate to let me know. Kind regards, Chris Amin and the RIPE Atlas team On 2015-07-20 15:39, Robert Kisteleki wrote: > On 2015-07-16 1:23, Yang Yu wrote: >> I have been having this issue with every feature that requires logging >> in on https://atlas.ripe.net. >> >> For instance, when I try to create an API key, HTTP POST to >> /keys/create/ gets a 302 to >> https://atlas.ripe.net/login?next=/keys/create/, then the new GET >> results in another 302 to https://atlas.ripe.net/keys/create/ and back >> to https://atlas.ripe.net/login?next=/keys/create/ until the browser >> gives up on redirecting and throws an error. >> >> Tested on Chrome/Firefox with Ubuntu trusty and Windows 7. Tried on a >> different computer from a different continent, still the same issue. > > Dear All, > > We've heard others reporting this issue as well. We have been, and > still are > looking into it. We can confirm that the issue is real, but it proves > difficult to track down the root cause. > > We'll report back with our findings, and hopefully a solution too, > shortly. > > Regards, > Robert Kisteleki, for the RIPE Atlas team From alexandre.abreu at vodafone.com Tue Jul 21 10:51:41 2015 From: alexandre.abreu at vodafone.com (Abreu, Alexandre, Vodafone Portugal) Date: Tue, 21 Jul 2015 08:51:41 +0000 Subject: [atlas] 1msec RTT to ipv6.google.com? Message-ID: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> Hi all Anyone had any issues with wrong RTTs on IPv6 probes? I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT on the seismograph and the json file. It is physically impossible. This is the RTT I get on the CPE the probe is connected to: SEQ HOST SIZE TTL TIME STATUS 0 2a00:1450:4003:806::200e 56 59 12ms echo reply 1 2a00:1450:4003:806::200e 56 59 12ms echo reply 2 2a00:1450:4003:806::200e 56 59 12ms echo reply 3 2a00:1450:4003:806::200e 56 59 12ms echo reply 4 2a00:1450:4003:806::200e 56 59 12ms echo reply 5 2a00:1450:4003:806::200e 56 59 12ms echo reply Regards, Alexandre Abreu From tom at hetmer.com Tue Jul 21 11:07:32 2015 From: tom at hetmer.com (=?iso-8859-2?B?VG9t4bkgSGV0bWVy?=) Date: Tue, 21 Jul 2015 11:07:32 +0200 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> Message-ID: Hi, I didn't observe this exact thing, but I've seen some weird traceroute outputs on a Windows box behind a Comtrend ADSL router. The PTRs returned were completely wrong and I think there were some other issues too.Once we replaced the CPE everything went back to normal, so I'd check that first, maybe it's doing something funny to the IPv6 traffic. Best regardsTom?? Hetmer > From: alexandre.abreu at vodafone.com > To: ripe-atlas at ripe.net > Date: Tue, 21 Jul 2015 08:51:41 +0000 > Subject: [atlas] 1msec RTT to ipv6.google.com? > > Hi all > > Anyone had any issues with wrong RTTs on IPv6 probes? I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT on the seismograph and the json file. It is physically impossible. This is the RTT I get on the CPE the probe is connected to: > > SEQ HOST SIZE TTL TIME STATUS > 0 2a00:1450:4003:806::200e 56 59 12ms echo reply > 1 2a00:1450:4003:806::200e 56 59 12ms echo reply > 2 2a00:1450:4003:806::200e 56 59 12ms echo reply > 3 2a00:1450:4003:806::200e 56 59 12ms echo reply > 4 2a00:1450:4003:806::200e 56 59 12ms echo reply > 5 2a00:1450:4003:806::200e 56 59 12ms echo reply > > Regards, > Alexandre Abreu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.abreu at vodafone.com Tue Jul 21 11:37:13 2015 From: alexandre.abreu at vodafone.com (Abreu, Alexandre, Vodafone Portugal) Date: Tue, 21 Jul 2015 09:37:13 +0000 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> Message-ID: <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> Hi Based on your feedback I've built a probe with the IP address instead of the hostname and I now get "normal" results. There's something weird about the DNS resolution that is leading to these results. Thanks for your help. AA From: th at outlook.cz [mailto:th at outlook.cz] On Behalf Of Tom?? Hetmer Sent: Tuesday, 21 de July de 2015 10:08 To: Abreu, Alexandre, Vodafone Portugal; ripe-atlas at ripe.net Subject: RE: [atlas] 1msec RTT to ipv6.google.com? Hi, I didn't observe this exact thing, but I've seen some weird traceroute outputs on a Windows box behind a Comtrend ADSL router. The PTRs returned were completely wrong and I think there were some other issues too. Once we replaced the CPE everything went back to normal, so I'd check that first, maybe it's doing something funny to the IPv6 traffic. Best regards Tom?? Hetmer > From: alexandre.abreu at vodafone.com > To: ripe-atlas at ripe.net > Date: Tue, 21 Jul 2015 08:51:41 +0000 > Subject: [atlas] 1msec RTT to ipv6.google.com? > > Hi all > > Anyone had any issues with wrong RTTs on IPv6 probes? I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT on the seismograph and the json file. It is physically impossible. This is the RTT I get on the CPE the probe is connected to: > > SEQ HOST SIZE TTL TIME STATUS > 0 2a00:1450:4003:806::200e 56 59 12ms echo reply > 1 2a00:1450:4003:806::200e 56 59 12ms echo reply > 2 2a00:1450:4003:806::200e 56 59 12ms echo reply > 3 2a00:1450:4003:806::200e 56 59 12ms echo reply > 4 2a00:1450:4003:806::200e 56 59 12ms echo reply > 5 2a00:1450:4003:806::200e 56 59 12ms echo reply > > Regards, > Alexandre Abreu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at romanrm.net Tue Jul 21 12:33:43 2015 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 21 Jul 2015 15:33:43 +0500 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> Message-ID: <20150721153343.1f87db41@natsu> On Tue, 21 Jul 2015 09:37:13 +0000 "Abreu, Alexandre, Vodafone Portugal" wrote: > Based on your feedback I've built a probe with the IP address instead of the hostname and I now get "normal" results. There's something weird about the DNS resolution that is leading to these results. Read about: https://peering.google.com/about/ggc.html Your probe may have resolved ipv6.google.com to the IP of your ISP's Google Global Cache mirror, hence the very low ping. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jeroen at dckd.nl Tue Jul 21 12:34:30 2015 From: jeroen at dckd.nl (Jeroen van der Ham) Date: Tue, 21 Jul 2015 12:34:30 +0200 Subject: [atlas] Probe downtime alert for IPv6? Message-ID: Hi, The portal offers a notification option for down time. I have a probe that is connected both over IPv4 and IPv6. The latter is through an IPv6 tunnel, which seems a bit flaky at times. I was hoping that the downtime notification would also hold for IPv6, but it turns out it doesn?t. Would it be possible that that be added? Thanks, Jeroen. From robert at ripe.net Tue Jul 21 12:50:37 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 21 Jul 2015 12:50:37 +0200 Subject: [atlas] Probe downtime alert for IPv6? In-Reply-To: References: Message-ID: <55AE23FD.50200@ripe.net> On 2015-07-21 12:34, Jeroen van der Ham wrote: > Hi, > > The portal offers a notification option for down time. > I have a probe that is connected both over IPv4 and IPv6. The latter is through an IPv6 tunnel, which seems a bit flaky at times. > I was hoping that the downtime notification would also hold for IPv6, but it turns out it doesn?t. Would it be possible that that be added? > > Thanks, > Jeroen. Hi, Probes try to keep an opne connection to the infrastructure using either IPv4 or IPv6. As long as this connection is up, they are happy. If this connection goes down for more than 30 minutes, then this notification mechanism is triggered. It follows that flakyness of the "other" protocol is not detected by this mechanism -- and it would be difficult to add it without maintaining parallel sessions using both protocols. It's technically possible to detect some of this flakyness by looking at the (real-time) results supplied by the probe. I don't think it's a simple exercise though. Regards, Robert From furry13 at gmail.com Tue Jul 21 13:31:33 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 21 Jul 2015 13:31:33 +0200 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: <20150721153343.1f87db41@natsu> References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> <20150721153343.1f87db41@natsu> Message-ID: On Tue, Jul 21, 2015 at 12:33 PM, Roman Mamedov wrote: > On Tue, 21 Jul 2015 09:37:13 +0000 > "Abreu, Alexandre, Vodafone Portugal" wrote: > >> Based on your feedback I've built a probe with the IP address instead of the hostname and I now get "normal" results. There's something weird about the DNS resolution that is leading to these results. > > Read about: https://peering.google.com/about/ggc.html > > Your probe may have resolved ipv6.google.com to the IP of your ISP's Google > Global Cache mirror, hence the very low ping. Does not look like that as the address is 2a00:1450:4003:806::200e which is Google VIP in Europe. -- SY, Jen Linkova aka Furry From rm at romanrm.net Tue Jul 21 13:46:07 2015 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 21 Jul 2015 16:46:07 +0500 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> <20150721153343.1f87db41@natsu> Message-ID: <20150721164607.13f132c9@natsu> On Tue, 21 Jul 2015 13:31:33 +0200 Jen Linkova wrote: > On Tue, Jul 21, 2015 at 12:33 PM, Roman Mamedov wrote: > > On Tue, 21 Jul 2015 09:37:13 +0000 > > "Abreu, Alexandre, Vodafone Portugal" wrote: > > > >> Based on your feedback I've built a probe with the IP address instead of the hostname and I now get "normal" results. There's something weird about the DNS resolution that is leading to these results. > > > > Read about: https://peering.google.com/about/ggc.html > > > > Your probe may have resolved ipv6.google.com to the IP of your ISP's Google > > Global Cache mirror, hence the very low ping. > > Does not look like that as the address is 2a00:1450:4003:806::200e > which is Google VIP in Europe. From the original message: > I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT > RTT I get on the CPE the probe is connected to > 0 2a00:1450:4003:806::200e 56 59 12ms echo reply My guess is that maybe the probe was set up to use a different DNS resolver than the CPE, and it got a different IPv6 instead of 2a00:1450:4003:806::200e. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From robert at ripe.net Tue Jul 21 13:54:48 2015 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 21 Jul 2015 13:54:48 +0200 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: <20150721164607.13f132c9@natsu> References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> <20150721153343.1f87db41@natsu> <20150721164607.13f132c9@natsu> Message-ID: <55AE3308.3070907@ripe.net> > From the original message: > >> I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT >> RTT I get on the CPE the probe is connected to >> 0 2a00:1450:4003:806::200e 56 59 12ms echo reply > > My guess is that maybe the probe was set up to use a different DNS resolver > than the CPE, and it got a different IPv6 instead of 2a00:1450:4003:806::200e. Indeed the probe pinged 2a00:1450:4004:801::200e and not the address above. I have no idea if that's the root cause for this, but it's certainly a different target. It could be the same DNS resolver but it got different answers at different times? I set up one-off traceroutes 2144086 (ICMP) and 2144089 (UDP) and they seem quite reasonable to me (5 hops, ~1.2ms to target). Robert From alexandre.abreu at vodafone.com Wed Jul 22 12:12:37 2015 From: alexandre.abreu at vodafone.com (Abreu, Alexandre, Vodafone Portugal) Date: Wed, 22 Jul 2015 10:12:37 +0000 Subject: [atlas] 1msec RTT to ipv6.google.com? In-Reply-To: <55AE3308.3070907@ripe.net> References: <8DC8F21627983444A6CB959F6DCFBD75985A51B1@VOEXM06W.internal.vodafone.com> <8DC8F21627983444A6CB959F6DCFBD75985A51DE@VOEXM06W.internal.vodafone.com> <20150721153343.1f87db41@natsu> <20150721164607.13f132c9@natsu> <55AE3308.3070907@ripe.net> Message-ID: <8DC8F21627983444A6CB959F6DCFBD75985A56DA@VOEXM06W.internal.vodafone.com> Hi I've been reviewing both paths and indeed 2a00:1450:4004:801::200e is 1msec away from the probe (it is answered right at the internet exchange premises by either Google's router or a colocated server/cache) while 2a00:1450:4004:806::200e has to go out to Google DCs hence the ~12msec. Thank you all for your help. AA -----Original Message----- From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Robert Kisteleki Sent: Tuesday, 21 de July de 2015 12:55 To: Roman Mamedov; Jen Linkova Cc: ripe-atlas at ripe.net; Tom?? Hetmer Subject: Re: [atlas] 1msec RTT to ipv6.google.com? > From the original message: > >> I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT >> RTT I get on the CPE the probe is connected to >> 0 2a00:1450:4003:806::200e 56 59 12ms echo reply > > My guess is that maybe the probe was set up to use a different DNS resolver > than the CPE, and it got a different IPv6 instead of 2a00:1450:4003:806::200e. Indeed the probe pinged 2a00:1450:4004:801::200e and not the address above. I have no idea if that's the root cause for this, but it's certainly a different target. It could be the same DNS resolver but it got different answers at different times? I set up one-off traceroutes 2144086 (ICMP) and 2144089 (UDP) and they seem quite reasonable to me (5 hops, ~1.2ms to target). Robert From BECHA at ripe.net Fri Jul 24 15:14:48 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 24 Jul 2015 15:14:48 +0200 Subject: [atlas] New on RIPE Labs: Extending RIPE atlas' Reach Message-ID: <55B23A48.50107@ripe.net> Dear colleagues, we are about to start experimenting with new outreach methods, in an effort to increase the growth rate of connected RIPE Atlas probes and achieve better coverage across the globe. Read more in this RIPE labs article: https://labs.ripe.net/Members/becha/extending-ripe-atlas-reach Regards, Vesna Manojlovic Measurements Community Building From colinj at mx5.org.uk Fri Jul 24 15:45:54 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 24 Jul 2015 14:45:54 +0100 Subject: [atlas] New on RIPE Labs: Extending RIPE atlas' Reach In-Reply-To: <55B23A48.50107@ripe.net> References: <55B23A48.50107@ripe.net> Message-ID: <92584549-5FEA-4E4B-B72D-640B4240AA26@mx5.org.uk> Hi Vesna, happy to distribute more probes for UK hosts via BT work contacts, albeit UK has high coverage as you know. shout if you want me to. I did mention to BT folks internally as a very useful monitoring solution. Have you thought about using the good services of the United Nations meetings as well ? Colin Johnston > On 24 Jul 2015, at 14:14, Vesna Manojlovic wrote: > > Dear colleagues, > > we are about to start experimenting with new outreach methods, > in an effort to increase the growth rate of connected > RIPE Atlas probes and achieve better coverage across the globe. > > Read more in this RIPE labs article: > https://labs.ripe.net/Members/becha/extending-ripe-atlas-reach > > Regards, > Vesna Manojlovic > Measurements Community Building > > From joachim at tingvold.com Mon Jul 27 01:35:06 2015 From: joachim at tingvold.com (Joachim Tingvold) Date: Mon, 27 Jul 2015 01:35:06 +0200 Subject: [atlas] ASN-information on Network tab Message-ID: <1B97FAE7-5C75-47AB-A806-E2DFAA1E05FF@tingvold.com> Hi, Any reason as to why the ASN numbers isn't displayed on the "Network" tab of a probe that is public? The ASN numbers is available on the probes list, so it would be practical to show it on the "Network" tab as well. -- Joachim From robert at ripe.net Mon Jul 27 09:21:15 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 27 Jul 2015 09:21:15 +0200 Subject: [atlas] ASN-information on Network tab In-Reply-To: <1B97FAE7-5C75-47AB-A806-E2DFAA1E05FF@tingvold.com> References: <1B97FAE7-5C75-47AB-A806-E2DFAA1E05FF@tingvold.com> Message-ID: <55B5DBEB.5050408@ripe.net> On 2015-07-27 1:35, Joachim Tingvold wrote: > Hi, > > Any reason as to why the ASN numbers isn't displayed on the "Network" tab of > a probe that is public? > > The ASN numbers is available on the probes list, so it would be practical to > show it on the "Network" tab as well. Yes, this would make sense -- and we can make it happen! Regards, Robert From joachim at tingvold.com Mon Jul 27 13:44:28 2015 From: joachim at tingvold.com (Joachim Tingvold) Date: Mon, 27 Jul 2015 13:44:28 +0200 Subject: [atlas] ASN-information on Network tab In-Reply-To: <55B5DBEB.5050408@ripe.net> References: <1B97FAE7-5C75-47AB-A806-E2DFAA1E05FF@tingvold.com> <55B5DBEB.5050408@ripe.net> Message-ID: <92CE9BDA-90EB-4B0B-AFE5-EB40D5E7111B@tingvold.com> On 27 Jul 2015, at 9:21, Robert Kisteleki wrote: > Yes, this would make sense -- and we can make it happen! Thank you (-: -- Joachim From Brett.Carr at nominet.org.uk Wed Jul 29 10:13:19 2015 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Wed, 29 Jul 2015 08:13:19 +0000 Subject: [atlas] APIs for accessing DNSMON data Message-ID: <20A45095-8977-42DC-8B90-E6765E1355B9@nominet.org.uk> Hello, last year there was a discussion on this list regarding API?s for accessing DNSMON data, I believe the intention was to discuss this at the Warsaw meeting, unfortunately I was not able to attend that meeting so I?m not really sure what the outcome of that discussion was. Nominet use DNSMON on a daily basis and would be very interested in using an API to access the data held in DNSMON. Thanks Brett -- Brett Carr Senior DNS Engineer Nominet UK From bortzmeyer at nic.fr Wed Jul 29 10:28:44 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 29 Jul 2015 10:28:44 +0200 Subject: [atlas] APIs for accessing DNSMON data In-Reply-To: <20A45095-8977-42DC-8B90-E6765E1355B9@nominet.org.uk> References: <20A45095-8977-42DC-8B90-E6765E1355B9@nominet.org.uk> Message-ID: <20150729082844.GA8217@nic.fr> On Wed, Jul 29, 2015 at 08:13:19AM +0000, Brett Carr wrote a message of 9 lines which said: > last year there was a discussion on this list regarding API?s > for accessing DNSMON data, I believe the intention was to > discuss this at the Warsaw meeting, unfortunately I was not able > to attend that meeting so I?m not really sure what the outcome > of that discussion was. No need for a specific API. Since DNSMON use Atlas, you just use the regular Atlas API. > Nominet use DNSMON on a daily basis and would be very interested in > using an API to access the data held in DNSMON. Same thing for us and we calculate the application of our SLAs from DNSMON data, downloaded, parsed (with Python) and presented as a nice spreadsheet to the relevant stakeholders. If you want some details, we can discuss it privately. From mcandela at ripe.net Wed Jul 29 10:41:46 2015 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 29 Jul 2015 10:41:46 +0200 Subject: [atlas] APIs for accessing DNSMON data In-Reply-To: <20150729082844.GA8217@nic.fr> References: <20A45095-8977-42DC-8B90-E6765E1355B9@nominet.org.uk> <20150729082844.GA8217@nic.fr> Message-ID: <2E897CB4-8666-4E51-91E4-22EC2624D693@ripe.net> Hello Brett, In addition to the Stephane suggestion, by clicking on one of the cell of DNSMON you will access to a pop-up with a series of links to all the API used to populate the visualisation. Ciao, Massimo Candela RIPE NCC On 29 Jul 2015, at 10:28, Stephane Bortzmeyer wrote: > On Wed, Jul 29, 2015 at 08:13:19AM +0000, > Brett Carr wrote > a message of 9 lines which said: > >> last year there was a discussion on this list regarding API?s >> for accessing DNSMON data, I believe the intention was to >> discuss this at the Warsaw meeting, unfortunately I was not able >> to attend that meeting so I?m not really sure what the outcome >> of that discussion was. > > No need for a specific API. Since DNSMON use Atlas, you just use the > regular Atlas API. > >> Nominet use DNSMON on a daily basis and would be very interested in >> using an API to access the data held in DNSMON. > > Same thing for us and we calculate the application of our SLAs from > DNSMON data, downloaded, parsed (with Python) and presented as a nice > spreadsheet to the relevant stakeholders. > > If you want some details, we can discuss it privately. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From robert at ripe.net Wed Jul 29 14:20:05 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 29 Jul 2015 14:20:05 +0200 Subject: [atlas] ASN-information on Network tab In-Reply-To: <92CE9BDA-90EB-4B0B-AFE5-EB40D5E7111B@tingvold.com> References: <1B97FAE7-5C75-47AB-A806-E2DFAA1E05FF@tingvold.com> <55B5DBEB.5050408@ripe.net> <92CE9BDA-90EB-4B0B-AFE5-EB40D5E7111B@tingvold.com> Message-ID: <55B8C4F5.8070304@ripe.net> On 2015-07-27 13:44, Joachim Tingvold wrote: > On 27 Jul 2015, at 9:21, Robert Kisteleki wrote: >> Yes, this would make sense -- and we can make it happen! > > Thank you (-: > FYI: this has been implemented and was deployed today. Regards, Robert From yang.yu.list at gmail.com Wed Jul 29 15:13:57 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 29 Jul 2015 22:13:57 +0900 Subject: [atlas] Case sensitive DNS queries from the probe Message-ID: Hello, Looking through DNS queries log I saw tons of queries from the probe for case sensitive names. Can someone please enlighten me what the possible use cases are? query: wWw.FacebOOK.COm IN A query: wWW.Wikia.COM IN A query: WwW.wIkIA.cOM IN A query: POOl.NTP.ORg query: Www.wikiA.CoM IN A query: wWW.FacebOoK.COM IN A query: wWw.faCeBOoK.cOM IN A Yang From bortzmeyer at nic.fr Wed Jul 29 15:17:20 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 29 Jul 2015 15:17:20 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: References: Message-ID: <20150729131720.GA11409@nic.fr> On Wed, Jul 29, 2015 at 10:13:57PM +0900, Yang Yu wrote a message of 18 lines which said: > Looking through DNS queries log I saw tons of queries from the probe > for case sensitive names. Can someone please enlighten me what the > possible use cases are? Probably a test of From philip.homburg at ripe.net Wed Jul 29 15:21:18 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 29 Jul 2015 15:21:18 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: References: Message-ID: <55B8D34E.8010604@ripe.net> On 2015/07/29 15:13 , Yang Yu wrote: > Looking through DNS queries log I saw tons of queries from the probe > for case sensitive names. Can someone please enlighten me what the > possible use cases are? > > query: wWw.FacebOOK.COm IN A Many years ago there was a proposal for stub resolvers to perform case mangling in DNS requests to obtain increased protection against spoofing attacks. This never became popular but is implemented in the stub resolver in libevent, which is used by the measurement code on the probes. Then net effect is that probes will send these types of queries whenever the measurement code needs to look up a DNS name to obtain a target's IP address. Philip From bortzmeyer at nic.fr Fri Jul 31 11:56:22 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 31 Jul 2015 11:56:22 +0200 Subject: [atlas] [UDM] Consistency in the timeout parameter Message-ID: <20150731095622.GA6708@nic.fr> If I read correctly , traceroute and NTP measurements have a "timeout" parameter but not ping or DNS. Why? From philip.homburg at ripe.net Fri Jul 31 12:06:14 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 31 Jul 2015 12:06:14 +0200 Subject: [atlas] [UDM] Consistency in the timeout parameter In-Reply-To: <20150731095622.GA6708@nic.fr> References: <20150731095622.GA6708@nic.fr> Message-ID: <55BB4896.2090207@ripe.net> Hi Stephane, I guess the answer is that it isn't requested often enough. For ping, we have a ticket somewhere to add it. For DNS I can't remember anyone talking out it. Do you have a specific use case? Philip From bortzmeyer at nic.fr Fri Jul 31 12:10:58 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 31 Jul 2015 12:10:58 +0200 Subject: [atlas] [UDM] Consistency in the timeout parameter In-Reply-To: <55BB4896.2090207@ripe.net> References: <20150731095622.GA6708@nic.fr> <55BB4896.2090207@ripe.net> Message-ID: <20150731101058.GA10243@nic.fr> On Fri, Jul 31, 2015 at 12:06:14PM +0200, Philip Homburg wrote a message of 7 lines which said: > For DNS I can't remember anyone talking out it. Count me in. > Do you have a specific use case? Yes, today, tools.ietf.org has a DNS problem and the majority of the probes do not send back an answer in time (those who do return SERVFAIL). I wanted to increase the timeout. From philip.homburg at ripe.net Fri Jul 31 12:13:49 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 31 Jul 2015 12:13:49 +0200 Subject: [atlas] [UDM] Consistency in the timeout parameter In-Reply-To: <20150731101058.GA10243@nic.fr> References: <20150731095622.GA6708@nic.fr> <55BB4896.2090207@ripe.net> <20150731101058.GA10243@nic.fr> Message-ID: <55BB4A5D.4000606@ripe.net> On 2015/07/31 12:10 , Stephane Bortzmeyer wrote: >> Do you have a specific use case? > > Yes, today, tools.ietf.org has a DNS problem and the majority of the > probes do not send back an answer in time (those who do return > SERVFAIL). I wanted to increase the timeout. I also noticed some issue with tools.ietf.org. I'll create a ticket to add the timeout parameter.