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: