- ripe-atlas - mailman.ripe.net

Testing DNS-over-TLS support?
by Stephane Bortzmeyer 10 Mar '17

10 Mar '17

DNS-over-TLS (RFC 7858) is important for privacy but, today, few DNS resolvers support it. It would be interesting to measure if this is changing, but the probes do not seem to be able to query their resolver with TLS over port 853. (Also, I seem to remember that old probes do not have a full TLS implementation.) It is not just a matter of encrypting the data, it's also an authentication issue (Google Public DNS was already impersonated <http://bgpmon.net/turkey-hijacking-ip-addresses-for-popular-global-dns-prov…>) So, how about adding a 'use_tls': True after 'use_probe_resolver': True?

2 2

No data in Connection & Traffic graph
by Danny Horne 09 Mar '17

09 Mar '17

Hi all, Is anyone not seeing any data on the Connection & Traffic graph in the General tab on their probe's homepage? (My probe ID 31491) Regards Danny Horne

2 1

Ripe website problems
by Danny Horne 08 Mar '17

08 Mar '17

Hi all, Anyone getting this when trying to get to access.ripe.net? Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /<https://access.ripe.net/>. Reason: Error reading from remote server

2 2

Failing probe, all lights blink
by Phillip Remaker 07 Mar '17

07 Mar '17

This is a new one for me. A V3 probe, when powered on, lights the power light, and then blinks all other lights for about a second every few seconds. Forever. I opened a case on it and was referred to the USB stick recovery process. Sigh. This is not that problem, I know how to deal with the USB stick issue. Has anyone seen this? Is there a deeper recovery trick we can use? I'm perfectly happy to attach a console to the TP-Link device. I was planning on doing it anyway to see what errors I am getting.

3 5

Probe Fulfilment
by Eduardo Duarte 06 Mar '17

06 Mar '17

Hi, I have craeted several measurements and the I always have a lower "Probe Fulfilment" rate. What does this mean? Thank you, Eduardo Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

HTTPS interception in Atlas probes
by Stephane Bortzmeyer 03 Mar '17

03 Mar '17

After this excellent talk at NDSS 17 <https://www.internetsociety.org/doc/security-impact-https-interception>, I wanted to see if there are some Atlas probes behind such an interceptor. I cannot run on all Atlas probes (maximum daily spending limit) but I've found at least one: % python cert.py --requested 500 --area North-Central --issuer www.afnic.fr 497 probes reported [<X509Name object '/C=NL/O=OCOM/OU=Security Dep/CN=amspan01.ocom.lan/emailAddress=security(a)leaseweb.com'>] : 1 occurrences [<X509Name object '/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Extended Validation CA - SHA256 - G2'>] : 496 occurrences Test #7854923 done at 2017-03-03T16:20:43Z The probe is #10035, in Amsterdam <https://atlas.ripe.net/probes/10035/#!tab-general> The cert.py program is at <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib>

1 0

Feature request: API call in results page
by Hugo Salgado 03 Mar '17

03 Mar '17

Hi RIPE Atlas people. I wonder if it could be possible to add an option on the "measurements" webpage of a previous stopped or running measurement, to be able to see the API call that created it. Just like the "Measurement API Compatible Specification" section, when you create one. It could be available just to the user who created it... and even with API keys obscured. That will be very handy to be able to replay and exact measurement, or to have the list of probes in a ready-to-use format. Thanks a lot! Hugo Salgado

2 1

USB stick?
by Danny Horne 02 Mar '17

02 Mar '17

Hi all, I've seen in another thread mention of a USB stick. I've got an Atlas probe coming and haven't seen mention of a USB stick anywhere else, just the need for an Ethernet connection and USB power adapter. Have I missed something? Thanks for looking Regards Danny

2 1

modifications to Atlas front-end servers
by Romeo Zwart 02 Mar '17

02 Mar '17

dear Pier, Bjørn and all, We are in the process of migrating the atlas front-end machinery from apache to nginx. Despite our extensive preparations, this change has not been completely transparent, as you have noticed, and has caused some problems with the certificate chains. The problems with the CERTs have now been fixed. Apologies for this inconvenience to everyone. Please let us know if you would spot any other anomalies in the behaviour of the Atlas service. Kind regards, Romeo Zwart

1 0

SSL issue with atlas.ripe.net
by Pier Carlo Chiodi - Active Network S.p.A. 02 Mar '17

02 Mar '17

Hello, I'm facing an issue while using Atlas API. Some connections (not all) to https://atlas.ripe.net fail because of what seems to be an invalid certs chain. It looks like that an intermediate cert is missing. SSLLabs too reports something similar: https://www.ssllabs.com/ssltest/analyze.html?d=atlas.ripe.net&s=193.0.6.158 $ openssl s_client -connect atlas.ripe.net:443 -servername atlas.ripe.net CONNECTED(00000003) depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=27:certificate not trusted verify return:1 depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA --- ... Verify return code: 21 (unable to verify the first certificate) -- Pier Carlo Chiodi - Active Network S.p.A. via della Chimica, 18 - 01100 Viterbo Tel: +39 0761 17691 08 - Fax: +39 06 23328079

2 1

changing probes of a given measurement
by JORDI PALET MARTINEZ 01 Mar '17

01 Mar '17

Hi, Is it possible to change some of the probes of a given measurement? The issue is that I’ve a set of 10 probes for a specific measurement and it seems that 1 of them is no longer connected. Last time I’d this situation, I created a new measurement with the same probes except the failed one, but I wonder if it is possible to “modify” the actual measurement instead of creating a new one? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 1

Probe lights
by Alistair Mackenzie 27 Feb '17

27 Feb '17

Hi, I'm not sure if I'm missing something but there doesn't seem to be a guide on what the lights mean nor even how to read the SOS messages coming from the probe. I've tried resetting the USB drive and I can write to it with my laptop so I don't suspect this is the problem. Is there any information on how to diagnose this probe? Thanks, Alistair

2 1

CHAOS DNS queries
by Kyle Schomp 23 Feb '17

23 Feb '17

Hi all, For chaos txt queries, the only qnames that ripe atlas currently allows are: "hostname.bind", "id.server", "version.bind", "version.server". This seems like an unnecessary limitation to me as I've used chaos txt many times in the past for various dynamic records. I'm wondering what other peoples thoughts are on this restriction. Is this a problem for anyone else? Perhaps if there is enough community interest, the ripe atlas devs might decide to remove the restriction. Thanks! -kyle

1 0

250 RIPE Atlas Anchors now online!
by Michela Galante 23 Feb '17

23 Feb '17

Dear colleagues, Thanks to nineteen new RIPE Atlas Anchors being activated over the last three months, we have now reached an important milestone: 250 anchors online! Congratulations to anchor 250 hosted by Mogul Service and Support LLC in Ulaanbaatar, Mongolia and to APNIC for sponsoring it! These are the other anchors that have become active since our last announcement in November: - nl-ede-as12859, hosted by BIT in Ede, Netherlands - de-tua-as21413, hosted by envia TEL GmbH in Taucha, Germany - de-ham-as12731, hosted by IPHH Internet Port Hamburg GmbH in Hamburg, Germany (replaces older hardware) - py-slo-as27733, hosted by IXpy (sponsored by LACNIC) in San Lorenzo, Paraguay - uk-did-as786, hosted by Jisc in Didcot, United Kingdom - Two anchors hosted by Rabobank: nl-bst-as8211 in Best and nl-bxt-as8211 in Boxtel, Netherlands - nz-wlg-as9834, hosted by Trade Me in Wellington, New Zealand - lt-vno-as21412, hosted by CGATES in Vilnius, Lithuania - de-ber-as25291, hosted by SysEleven GmbH in Berlin, Germany (replaces older hardware) - us-bcb-as1312, hosted by Virginia Tech Transportation Institute in Blacksburg, United States - Two anchors hosted by Elisa Obj: fi-hel-as6667 in Helsinki and fi-tmp-as719 in Tampere, Finland - lu-ezt-as2602, hosted by Fondation RESTENA in Esch-sur-Alzette, Luxembourg (replaces older hardware) - de-kae-as8560, hosted by 1&1 Internet SE in Karlsruhe, Germany - fr-par-as5377, hosted by Marlink Enterprise AS in Paris, France - fr-tls-as39405, hosted by FULLSAVE in Toulouse, France - nl-ams-as286, hosted by KPN Eurorings B.V. in Amsterdam, Netherlands - mm-rgn-as132167, hosted by Ooredoo Myanmar (sponsored by APNIC) in Yangon, Myanmar (IPv4-only anchor) - fr-ilm-as57119, hosted by NAITWAYS in Issy, France - us-lxa-as8560, hosted by 1&1 Internet Inc. in Lenexa, United States You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas Anchors online: https://atlas.ripe.net/anchors/list/ Interested in hosting a RIPE Atlas Anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ There are several organisations that want to host a RIPE Atlas Anchor but don’t have the necessary funding. Find out more about the RIPE NCC campaign to sponsor 15 RIPE Atlas Anchors https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas… We would also like to remind you about our ongoing cooperation with APNIC, LACNIC, AFRINIC and ISOC: thanks to their help we are getting more geographical diversity to the measurement data. If your organisation is in their region contact us at <atlas(a)ripe.net> and we will get you in touch with them! And don’t forget to let us know by contacting us at <atlas(a)ripe.net> if you’re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC

1 0

Atlas anchor Error message in the Bootlog
by Stanish Stanishev 22 Feb '17

22 Feb '17

Hello, I've installed the software on our Atlas anchor, however I noticed the following error message in the Boot Log: Error adding default gateway 213.91.165.187 for eth0. (213.91.165.187 is the IP addr assigned as def GW, eth0 is connected to the router and it is Up) Has anyone faced this issue ? I've sent an email to atlas(a)ripe.net for troubleshooting assistance but nobody has replied so far. Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

Querying popular domains with RIPE Atlas
by Chris Amin 21 Feb '17

21 Feb '17

Dear colleagues, As you are probably aware, DNSMON* and RIPE Atlas built-in** measurements are often used when analysing outages and other issues with important DNS services, particularly the root zone servers. These measurements do not provide a direct indication of the impact on actual end-user experience because they involve directly querying authoritative name servers, thereby ignoring the effects of having multiple authoritative name servers as well as caching local recursive resolvers. To improve upon our DNS monitoring, we will initiate two built-in DNS measurements from all RIPE Atlas probes that use the probes' default resolvers instead of authoritative name servers. The first measurement will query for random top-level domains with the intention of avoiding caches and therefore hitting at least one root name server. The second measurement will query for popular domain names, with the intention of hitting caches where appropriate and getting an idea of the true impact on users. As a starting point for the second measurement, we will use a recent snapshot of the global top 50 visited sites according to the Alexa top sites list***, which combines unique visitors and individual page views in its calculations. Probes will cycle through these domains, querying for a different A record every 10 minutes. Since DNS queries containing these domains will be made from every connected RIPE Atlas probe, we would like to ask for feedback on whether querying the DNS for any of these domains could pose legal or political problems for probe hosts in certain parts of the world. I have also included the next 25 most popular domains below, which will be used to fill any gaps caused by removing items from the main list. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/dnsmon/ ** https://atlas.ripe.net/docs/built-in/ *** https://en.wikipedia.org/w/index.php?title=List_of_most_popular_websites&ol… Provisional 50 domains to query =============================== google.com. youtube.com. facebook.com. baidu.com. wikipedia.org. yahoo.com. google.co.in. amazon.com. qq.com. google.co.jp. live.com. taobao.com. vk.com. twitter.com. instagram.com. hao123.com. sohu.com. sina.com.cn. reddit.com. google.de. linkedin.com. tmall.com. yahoo.co.jp. weibo.com. google.fr. 360.cn. google.co.uk. google.ru. google.com.br. yandex.ru. ebay.com. bing.com. msn.com. google.it. soso.com. t.co. wordpress.com. google.es. microsoft.com. tumblr.com. aliexpress.com. blogspot.com. netflix.com. amazon.co.jp. ok.ru. google.com.hk. stackoverflow.com. google.ca. google.com.mx. imgur.com. Next 25 most popular domains, excluding pornography =================================================== apple.com. Naver.com. mail.ru. imdb.com. popads.net. onclickads.net. office.com. google.co.kr. github.com. pinterest.com. paypal.com. tianya.cn. google.com.tw. google.com.tr. google.com.au. diply.com. amazon.de. google.co.id. microsoftonline.com. onclckds.com. twitch.tv. adobe.com. amazon.co.uk. wikia.com. cnzz.com.

3 3

Reminder: Ten Days Left to Apply for "DNS Measurements Hackathon"
by Vesna Manojlovic 16 Feb '17

16 Feb '17

Dear colleagues, The fifth RIPE NCC hackathon will take place on Thursday and Friday, 20-21 April 2017, in Amsterdam. Apply online: https://atlas.ripe.net/hackathon/dns-measurements/#!application-form *The application deadline is 26 February 2017* Find out more in this RIPE Labs article: https://labs.ripe.net/Members/alun_davies/dns-measurements-hackathon-2017 Regards, Vesna Manojlovic RIPE NCC Community Builder

1 0

New on RIPE Labs: Update on RIPE Atlas Probe Lifetimes
by Mirjam Kuehne 15 Feb '17

15 Feb '17

Dear colleagues, Please find an update on the status of RIPE Atlas probe connection times on RIPE Labs: https://labs.ripe.net/Members/wilhelm/update-on-atlas-probe-lifetimes Kind regards, Mirjam Kuhne RIPE NCC

1 0

Streaming API, endTime parameter is ignored
by Roberto Nunziato 10 Feb '17

10 Feb '17

Hello everybody, I am an Italian student and I am working with the RIPE Atlas Streaming API. I am trying to replay events that have happened in the past, so I am using the optional parameter endTime in the code below. Now, the stream starts at the specified time but it never ends. Am I doing anything wrong? Is this a bug? var socket = io(“https://atlas-stream.ripe.net <https://atlas-stream.ripe.net/>:443” , {path: “/stream/socket.io <http://socket.io/>”}); startTime = 1486256400 //05-02-17 h: 01:00GMT endTime = 1486258200 //05-02-17 h: 01:30GMT socket.emit(“atlas_subscribe”, {stream_type: “result”, startTime: startTime, endTime: endTime, msm: 1962548}); Best, Roberto Nunziato

2 3

New on RIPE Labs: Campaign to Sponsor 15 RIPE Atlas Anchors
by Mirjam Kuehne 31 Jan '17

31 Jan '17

Dear colleagues, The RIPE NCC is pleased to announce that we will be sponsoring 15 new RIPE Atlas anchors in 2017. This article provides details about the campaign and introduces the criteria that will be used to decide which applicants will receive sponsorship: https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas… Kind regards, Mirjam Kuhne RIPE NCC

1 0

Reporting incorrect locations
by Marty Strong 30 Jan '17

30 Jan '17

Hi RIPE Atlas folks, Is there somewhere we can go to report a suspected incorrect location of an Atlas probe? This probe: https://atlas.ripe.net/probes/16578/ Is marked as in China, but is clearly in Australia. I couldn’t see anywhere I should report this. Marty

2 3

high v6 user-base, less atlas probes
by Bajpai, Vaibhav 28 Jan '17

28 Jan '17

Hello, -- sorry for cross-posting Here is a list of top 20 countries that have a large v6 user-base [*] but are underrepresented by RIPE Atlas due to less number of deployed dual-stacked probes. Consider hosting a dual-stacked probe in these regions to help remove the region-based bias that v6 studies using RIPE Atlas may otherwise have: Full paper available here: http://goo.gl/hWGveA (§4) +----+------------+-----------| | CC | v6 Users | v6 Probes | |-----+----+------------+-----------| | 01 | BE | 56.48 % | 2.82 % | | 02 | LU | 35.23 % | 0.61 % | | 03 | GR | 33.66 % | 1.39 % | | 04 | CH | 33.48 % | 3.82 % | | 05 | PT | 29.01 % | 0.74 % | | 06 | IN | 22.25 % | 0.09 % | | 07 | US | 33.00 % | 13.21 % | | 08 | DE | 40.07 % | 21.25 % | | 09 | EC | 18.76 % | 0.04 % | | 10 | JP | 19.69 % | 1.35 % | | 11 | GB | 24.63 % | 7.00 % | | 12 | EE | 16.55 % | 0.26 % | | 13 | CA | 17.83 % | 1.91 % | | 14 | FI | 16.68 % | 1.39 % | | 15 | MY | 14.90 % | 0.13 % | | 16 | IE | 13.22 % | 0.87 % | | 17 | NO | 14.02 % | 1.83 % | | 18 | BR | 12.56 % | 0.83 % | | 19 | AU | 12.76 % | 1.09 % | |-----+----+------------+-----------| [*] The estimation of number of IPv6 users is taken from APNIC dataset: http://labs.apnic.net/dists/v6dcc.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------

1 0

RIPE Atlas Interface Hackathon, 21-22 May, Copenhagen
by Vesna Manojlovic 23 Jan '17

23 Jan '17

Dear colleagues, Calling all front-end developers, UI designers, network operators and other enthusiastic coders! The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* Please note that we are unfortunately unable to provide travel or accommodation funding. We look forward to seeing you there! Regards, Vesna and the RIPE Atlas Team

1 4

RIPE Atlas v1 APIs have been decommissioned
by Robert Kisteleki 20 Jan '17

20 Jan '17

Dear All, As we've been announcing it for a while now (see https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-September/003017.ht… and https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-January/003128.html) the v1 APIs were to be decommissioned by the end of last year / early this year. This step actually happened on Wednesday this week (18 January, around 14h CET). This means that queries to these APIs give 404s (for GETs) and 405s (for other methods, which we may change to 404 instead). This is also the cause for the issues Stéphane was experiencing. Full documentation on the v2 APIs and other features are available at https://atlas.ripe.net/docs/ Apologies for not sending this mail already on Wednesday. Regards, Robert Kisteleki RIPE NCC

1 0

traceroute measurement with abnormally small RTT
by Wenqin SHAO 19 Jan '17

19 Jan '17

Dear list, I recently found a ‘weird’ traceroute measurement record in the sense that: with paris id set, it has different IP addresses for a given hop; after it reached the destination, it tried one more hop; the final hop reported abnormally small RTT. I’d appreciate your views on how this happened. Here is how to identify the measurement in question: (the concerned record is as well provided at the end the mail) from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=5010, probe_ids=[10460], start=1482177890, stop=1482177900) _, results = AtlasResultsRequest(**filters).create() It’s a IPv4 traceroute measurement toward DNS b root, 192.228.79.201. What you’ll see is: starting from hop 14, the 3 measurements for the same hop come from different IP address: hop 14: 184.105.80.202, 72.52.92.122 hop 15: 72.52.92.122, 216.218.223.28 hop 16: 216.218.223.28, 130.152.181.189 hop 17: 130.152.181.189, 206.117.5.22 hop 18: 206.117.5.22, 192.228.79.201 hop 19: 192.228.79.201 My first doubt is with Paris traceroute is it still possible that response IP can change due to LB mechanism on the returning path? At hop 18, the traceroute actually already reached the destination, but it continued to perform the hop 19, why? At hop 19, there is one measurement from 192.228.79.201 reporting abnormally small RTT of 0.449ms. How come? Can that happen to other measurements as well, under what circumstances? The above listed neighbouring hops always share one IP address, which makes it seem like a data formatting issue. Is there a known bug? Thanks in advance for your attention. Best regards, wenqin Here below the measurement in question: ==== [ { "lts":-1, "size":40, "from":"176.227.133.141", "dst_name":"192.228.79.201", "fw":4740, "proto":"UDP", "af":4, "msm_name":"Traceroute", "prb_id":10460, "result":[ { "result":[ { "rtt":0.533, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.418, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.405, "ttl":255, "from":"192.168.1.1", "size":28 } ], "hop":1 }, { "result":[ { "x":"*" }, { "x":"*" }, { "x":"*" } ], "hop":2 }, { "result":[ { "rtt":677.27, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":660.216, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":709.112, "ttl":253, "from":"10.130.162.13", "size":28 } ], "hop":3 }, { "result":[ { "rtt":666.445, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":995.219, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":668.192, "ttl":252, "from":"10.130.162.250", "size":28 } ], "hop":4 }, { "result":[ { "rtt":681.02, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":652.502, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":673.857, "ttl":250, "from":"10.130.162.82", "size":28 } ], "hop":5 }, { "result":[ { "rtt":685.088, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":665.164, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":657.344, "ttl":250, "from":"88.202.127.129", "size":28 } ], "hop":6 }, { "result":[ { "rtt":669.097, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":743.974, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":637.311, "ttl":249, "from":"88.202.127.121", "size":28 } ], "hop":7 }, { "result":[ { "ttl":243, "rtt":692.425, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":659.768, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":698.084, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 } ], "hop":8 }, { "result":[ { "ttl":247, "rtt":684.096, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":685.871, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":736.12, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 } ], "hop":9 }, { "result":[ { "rtt":675.198, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":671.127, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":683.236, "ttl":246, "from":"10.130.1.201", "size":28 } ], "hop":10 }, { "result":[ { "rtt":736.688, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":697.844, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":818.184, "ttl":54, "from":"37.49.236.10", "size":28 } ], "hop":11 }, { "result":[ { "rtt":992.33, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":920.759, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":966.019, "ttl":53, "from":"184.105.213.173", "size":28 } ], "hop":12 }, { "result":[ { "x":"*" }, { "rtt":428.86, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":372.607, "ttl":52, "from":"184.105.80.202", "size":28 } ], "hop":13 }, { "result":[ { "rtt":448.726, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":427.897, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":550.12, "ttl":51, "from":"72.52.92.122", "size":28 } ], "hop":14 }, { "result":[ { "rtt":422.308, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":447.841, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":339.084, "ttl":241, "from":"216.218.223.28", "size":68 } ], "hop":15 }, { "result":[ { "rtt":470.177, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":338.323, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":482.44, "ttl":241, "from":"130.152.181.189", "size":68 } ], "hop":16 }, { "result":[ { "rtt":359.104, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":630.604, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":195.704, "ttl":48, "from":"206.117.5.22", "size":68 } ], "hop":17 }, { "result":[ { "rtt":759.236, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":369.954, "ttl":48, "from":"192.228.79.201", "size":68 }, { "rtt":431.369, "ttl":48, "from":"192.228.79.201", "size":68 } ], "hop":18 }, { "result":[ { "rtt":397.795, "ttl":48, "from":"192.228.79.201", "size":68 }, { "x":"*" }, { "ttl":48, "rtt":0.449, "ittl":2, "from":"192.228.79.201", "size":68 } ], "hop":19 } ], "timestamp":1482177892, "src_addr":"192.168.1.115", "paris_id":15, "endtime":1482177928, "type":"traceroute", "dst_addr":"192.228.79.201", "msm_id":5010 } ]

2 1