From astracha at ripe.net Wed May 6 10:23:30 2015 From: astracha at ripe.net (Alastair Strachan) Date: Wed, 6 May 2015 10:23:30 +0200 Subject: [atlas] Wikia in San Jose, USA has joined RIPE Atlas Anchors Message-ID: <82EFC398-B3DF-43D4-A9AC-550BBFDF482B@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 us-sjc-as22300 and it is hosted by Wikia in San Jose (USA) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From scott.rose at nist.gov Wed May 13 19:07:45 2015 From: scott.rose at nist.gov (Rose, Scott W.) Date: Wed, 13 May 2015 13:07:45 -0400 Subject: [atlas] Atlas and TLSA RR's? Message-ID: Hello, We have a TLSA test tool called DANELaw (https://www.had-pilot.com/dane/danelaw.html). The tool basically check for a TLSA RR for a given domain name and makes sure it matches the presented TLS certificate. Over the last few days we noticed a large volume of tests for TLSA RR's ending in "anchor.atlas.ripe.net". This isn't a big deal (except for our crude logging system), just wondering if this is a self-check, or some test. Also, our tool isn't really a production service, so if it goes down - will it effect anything? Scott =================================== Scott Rose NIST scott.rose at nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =================================== From astracha at ripe.net Thu May 14 08:43:09 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 14 May 2015 08:43:09 +0200 Subject: [atlas] M-net Telekommunikations GmbH in Munich has joined RIPE Atlas Anchors Message-ID: <16F909DB-72DD-4D0B-9501-2AAC02BEC945@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 de-muc-as8767 and it is hosted by M-net Telekommunikations GmbH in Munich Germany Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From BECHA at ripe.net Thu May 14 17:27:03 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 14 May 2015 17:27:03 +0200 Subject: [atlas] New on RIPE Labs: AMS-IX Outage during RIPE70 as Seen with RIPE Atlas In-Reply-To: <5554BD35.6000608@ripe.net> References: <5554BD35.6000608@ripe.net> Message-ID: <5554BEC7.4040500@ripe.net> FYI -------- Forwarded Message -------- Subject: [mat-wg] New on RIPE Labs: AMS-IX Outage during RIPE 70 as Seen with RIPE Atlas Date: Thu, 14 May 2015 17:20:21 +0200 From: Mirjam Kuehne To: mat-wg at ripe.net Dear colleagues, Please find this new article on RIPE Labs including some visualisations of yesterday's AMS-IX network outage: https://labs.ripe.net/Members/kistel/the-ams-ix-outage-as-seen-with-ripe-atlas Kind regards, Mirjam Kuehne RIPE NCCC From bortzmeyer at nic.fr Fri May 15 06:50:41 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 15 May 2015 06:50:41 +0200 Subject: [atlas] Invalid JSON because of DNS TXT records Message-ID: <20150515045041.GA29265@sources.org> The DNS, as we know, is a jungle. People put anything in their TXT records, even control characters. Atlas faithfully returns this content in the JSON files (see measurement #2004707). Then they are no longer legal JSON (RFC 7159, section 7) and crash the JSON libraries. Who should fix it? My first guess is that Atlas should not produce illegal JSON files and therefore should escape such texts. From philip.homburg at ripe.net Fri May 15 12:07:25 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 15 May 2015 12:07:25 +0200 Subject: [atlas] Invalid JSON because of DNS TXT records In-Reply-To: <20150515045041.GA29265@sources.org> References: <20150515045041.GA29265@sources.org> Message-ID: <5555C55D.1090306@ripe.net> Hi Stephane, On 2015/05/15 6:50 , Stephane Bortzmeyer wrote: > The DNS, as we know, is a jungle. People put anything in their TXT > records, even control characters. > > Atlas faithfully returns this content in the JSON files (see > measurement #2004707). Then they are no longer legal JSON (RFC 7159, > section 7) and crash the JSON libraries. > > Who should fix it? My first guess is that Atlas should not produce > illegal JSON files and therefore should escape such texts. We already noticed various issues in this area. What goes wrong is the following. The probes avoid sending binary data by converting characters outside the printable ASCII range the an escape sequence using the '\u' notation. So for example for a control-Z the probe sends '\u001A'. The problem with this approach is that this escape sequence is actually defined by the JSON specs. So some of our backend code recognizes the escape sequence and converts it back to the control character. After that, there is a bug somewhere. And escaped characters sometimes end up in result downloads. After internal discussions, the best way forward seems to be to change the escape sequence. This way we don't have to rely on JSON parsers to leave the escape sequence unchanged. One option is to double the backslash and have probes send '\\u001A'. But maybe anybody has a better idea. Philip From elane at ripe.net Fri May 15 15:02:38 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 15 May 2015 15:02:38 +0200 Subject: [atlas] University Carlos III of Madrid, Leganes, Spain 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 es-leg-as766 and is hosted by University Carlos III of Madrid, Leganes, Spain. 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 d.baeza at tvt-datos.es Fri May 15 18:28:59 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Fri, 15 May 2015 18:28:59 +0200 Subject: [atlas] Big latency change Message-ID: <55561ECB.4000005@tvt-datos.es> Hi folks, How can I check what happened at 13:00 (Dont know if the time in my probe is UTC or UTC+2) of today in the a.root-servers.net? My latency with the a-root changed from 117 to 45ms and Im curious of what happened. I've took a look in the RIPEstat routing for the IP Address of the root server, and at the same time the BGP had changes, but there are too many AS involved I cant follow it. Thanks in advance! -- Daniel Baeza From robert at ripe.net Fri May 15 19:37:52 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 15 May 2015 19:37:52 +0200 Subject: [atlas] Big latency change In-Reply-To: <55561ECB.4000005@tvt-datos.es> References: <55561ECB.4000005@tvt-datos.es> Message-ID: <55562EF0.907@ripe.net> On 2015-05-15 18:28, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi folks, > > How can I check what happened at 13:00 (Dont know if the time in my probe is > UTC or UTC+2) of today in the a.root-servers.net? > > My latency with the a-root changed from 117 to 45ms and Im curious of what > happened. > > I've took a look in the RIPEstat routing for the IP Address of the root > server, and at the same time the BGP had changes, but there are too many AS > involved I cant follow it. > > > Thanks in advance! Hi, a-root is anycasted, so most likely your probe switched to a different instance of the server. You can see their instances here: https://atlas.ripe.net/contrib/root_anycast.html?msm_id=9 You can check dns measurements your probe does and see if this is indeed the case -- they are available to you in the probe status page, built-in measurements tab. Perhaps "v4 DNS to a.root-servers.net (UDP hostname.bind)" is the best to try. Similarly, traceroutes could tell you exactly what changed. (We report all times in UTC) Cheers, Robert From d.baeza at tvt-datos.es Sat May 16 09:58:42 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Sat, 16 May 2015 09:58:42 +0200 Subject: [atlas] Big latency change In-Reply-To: <55562EF0.907@ripe.net> References: <55561ECB.4000005@tvt-datos.es> <55562EF0.907@ripe.net> Message-ID: <5556F8B2.5030507@tvt-datos.es> Hi Robert, Thanks for you answer but the only built-in graphs are for ping. The v4/v6 dns are only available for download in json. Also, how can I see an "old" traceroute, I mean the one before the latency did go down? Regards, El 15/05/2015 a las 19:37, Robert Kisteleki escribi?: > On 2015-05-15 18:28, Daniel Baeza (Red y Sistemas TVT) wrote: >> Hi folks, >> >> How can I check what happened at 13:00 (Dont know if the time in my probe is >> UTC or UTC+2) of today in the a.root-servers.net? >> >> My latency with the a-root changed from 117 to 45ms and Im curious of what >> happened. >> >> I've took a look in the RIPEstat routing for the IP Address of the root >> server, and at the same time the BGP had changes, but there are too many AS >> involved I cant follow it. >> >> >> Thanks in advance! > > Hi, > > a-root is anycasted, so most likely your probe switched to a different > instance of the server. You can see their instances here: > https://atlas.ripe.net/contrib/root_anycast.html?msm_id=9 > > You can check dns measurements your probe does and see if this is indeed the > case -- they are available to you in the probe status page, built-in > measurements tab. Perhaps "v4 DNS to a.root-servers.net (UDP hostname.bind)" > is the best to try. Similarly, traceroutes could tell you exactly what changed. > > (We report all times in UTC) > > Cheers, > Robert > -- Daniel Baeza From inigo at infornografia.net Sat May 16 11:25:20 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Sat, 16 May 2015 10:25:20 +0100 Subject: [atlas] Big latency change In-Reply-To: <5556F8B2.5030507@tvt-datos.es> References: <55561ECB.4000005@tvt-datos.es> <55562EF0.907@ripe.net> <5556F8B2.5030507@tvt-datos.es> Message-ID: Hola Daniel My probe (#10611) for instance also saw a change in routing towards A-root around the same time [1]. On Sat, May 16, 2015 at 8:58 AM, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi Robert, > > Thanks for you answer but the only built-in graphs are for ping. The v4/v6 > dns are only available for download in json. Indeed, built-in graphs only visualise ping latencies, but it is not hard to get what you want out of the raw JSON files. Please see [2]. Apparently, I was no longer hitting their site at NYC but LON. > Also, how can I see an "old" traceroute, I mean the one before the latency > did go down? The measurement API allows you to download measurement results in bulk, but also allows you to filter what data you're interested in (which probe, start and stop datetime, etc), please see [3]. If you want older traceroute data, just tell the API in which time window you are interested. HTH, [1] https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.measurement_id=1009&w.probe_id=10611&w.starttime=2015-05-09T09%3A03%3A17&w.endtime=2015-05-16T09%3A03%3A17&w.resolution=1h [2] [ops at eh ~]$ curl -so- 'https://atlas.ripe.net/api/v1/measurement/10309/result/?start=1431693000&stop=1431696600&prb_id=10611&format=json' | jq .[].result.answers[].RDATA "nnn1-nyc3" "nnn1-lon3" [3] https://atlas.ripe.net/docs/rest/ -- "If you want to go fast, go alone. If you want to go far, go together." From astracha at ripe.net Thu May 21 09:31:29 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 21 May 2015 09:31:29 +0200 Subject: [atlas] ICANN in El Segundo (US) 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 us-els-as40528 and it is hosted by ICANN in El Sugundo. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From astracha at ripe.net Thu May 21 09:33:20 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 21 May 2015 09:33:20 +0200 Subject: [atlas] ALTUSHOST B.V. in Dronten (NL) has joined RIPE Atlas Anchors Message-ID: <5A041AFE-1C2C-4AD8-8A4B-2A3480076DD3@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 nl-dro-as51430 and it is hosted by ALTUSHOST B.V. in Dronten (NL). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From woeber at cc.univie.ac.at Thu May 21 14:26:43 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 21 May 2015 14:26:43 +0200 Subject: [atlas] Big latency change In-Reply-To: <55561ECB.4000005@tvt-datos.es> References: <55561ECB.4000005@tvt-datos.es> Message-ID: <555DCF03.5050008@cc.univie.ac.at> I can see a similar change on the 3 Probes I have access to (1x V1 + 1 Anchor, close to each other, one on a different upstream). The maybe more interesting thing is that for 2 out of the 3, *after* the decrease of RTT, there were short bursts of RTT > than the previouse ~100+ : ~250ms and ~300ms. So, whatever the change was, it would be intersting to ask those folks if the change was intended or a side-effect of another event in the 'net... On 2015-05-15 18:28, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi folks, > > How can I check what happened at 13:00 (Dont know if the time in my probe is UTC or UTC+2) of today in the a.root-servers.net? > > My latency with the a-root changed from 117 to 45ms and Im curious of what happened. > > I've took a look in the RIPEstat routing for the IP Address of the root server, and at the same time the BGP had changes, but there are too many AS involved I cant follow it. > > > Thanks in advance! FWIW, Wilfried From astracha at ripe.net Fri May 22 16:33:02 2015 From: astracha at ripe.net (Alastair Strachan) Date: Fri, 22 May 2015 16:33:02 +0200 Subject: [atlas] Marist College (US) has joined RIPE Atlas Anchors Message-ID: <6B991C77-E727-45C7-B88F-ACDDFE3E2598@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 us-pou-as6124 and it is hosted by Marist College in Poughkeepsie, US. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From iortiz at ripe.net Tue May 26 18:59:10 2015 From: iortiz at ripe.net (=?windows-1252?Q?I=F1igo_Ortiz_de_Urbina_Cazenave?=) Date: Tue, 26 May 2015 18:59:10 +0200 Subject: [atlas] Atlas and TLSA RR's? In-Reply-To: References: Message-ID: <5564A65E.5010603@ripe.net> Hi Scott, Even though we?ve now discussed this off-list, I would like to repeat my response here on the mailing list, for the sake of transparency. On 13/05/15 19:07, Rose, Scott W. wrote: > Hello, > We have a TLSA test tool called DANELaw (https://www.had-pilot.com/dane/danelaw.html). The tool basically check for a TLSA RR for a given domain name and makes sure it matches the presented TLS certificate. Over the last few days we noticed a large volume of tests for TLSA RR's ending in "anchor.atlas.ripe.net". This isn't a big deal (except for our crude logging system), just wondering if this is a self-check, or some test. First off, thank you for making the check publicly available - it is one of the few services currently available for DANE-related web-checks and it is very useful. As you are now aware, this is a check I configured to ensure the TLSA records generated for every RIPE Atlas anchor are actually validated. As such, the check interval is equal to the TTL of the TLSA RR. We've also been working on a similar check we can deploy internally, so we will soon stop querying your service. > Also, our tool isn't really a production service, so if it goes down - will it effect anything? No, it will not affect anything in production. Quite the opposite: before we discussed this privately, I was concerned we could be negatively affecting your environment. While you test your new code, you can bring the service down for as long as you need to. Cheers, I?igo Ortiz de Urbina Cazenave RIPE NCC From astracha at ripe.net Thu May 28 16:15:58 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 28 May 2015 16:15:58 +0200 Subject: [atlas] ICANN (US) 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 us-rtv-as16876 and it is hosted by ICANN in Reston (US) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From astracha at ripe.net Thu May 28 16:16:00 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 28 May 2015 16:16:00 +0200 Subject: [atlas] Matrix DATA (NL) has joined RIPE Atlas Anchors Message-ID: <46C25F07-9C5E-4BEB-A515-87490A7C24DF@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 nl-hrd-as34612 and it is hosted by Matrix DATA in Harderwijk (NL) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: