Global Traceroute
I wrote front-end to traceroute from the RIPE Atlas probes. It looks like a standard looking glass — you select a probe by location and AS number, enter a destination, and it does a traceroute. It’s on the web at https://www.globaltraceroute.com. If this looks useful, please check it out and tell me what you think. One of the things I've found frustrating when troubleshooting routing problems was the lack of information about inbound paths. Various measurement systems would tell me when performance was bad. Traceroutes from my own network would tell me what path traffic to a destination was taking outbound. Flow systems would tell me what interface inbound traffic was coming in on, and sometimes what peer it was coming through. But determining the full path inbound traffic was taking — why users of some ISP in Asia were having their traffic show up at one of my POPs in Europe, for instance, was much more difficult. I’ve been using looking glasses and commercial performance monitoring systems that allow traceroutes from their probes, but those often weren’t where the end users were. RIPE Atlas did have probes where a lot of my end users were, so I started configuring one time measurements on RIPE Atlas whenever I needed a traceroute from a simulated end user. But finding a suitable probe and configuring the measurement was too cumbersome to do when I wasn’t pretty desperate. This is my attempt to solve that problem. Thanks, Steve
Hello. Thank you for your work. I will summarize my wishes: 1) After clicking the "Submit" button, the picture on the page should be shown, that the request is coming or the text "Loading ....", so that the user realizes that the request is not fast and did not hurry to leave the page. 2) If there is only one probes in the selected ASN, then after selecting ASN, this probe should also be selected. 3) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178 the top fields of sample #19178 are automatically filled. 4) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top fields of sample #19178 were automatically filled, in "Target Address" the value 1.1.1.1 was set and the request for construction trails. 5) It would be desirable that when https request https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly take a probe from the selected location (UK), automatically fill the top fields of this sample, the "Target Address" was exposed value 1.1.1.1 and automatically sent a request to build the route. 6) I want to work correctly in the console programs curl, lynx and wget. 7) Notes at the end of the route that "Target Address" is anycast address, especially for IP facebook, google, youtube and cloudflare. 8) reCAPTCHA is certainly good against abuse, but is more accountable limits on the number of requests. It is possible, after authorization through Google or facebook, to raise the limits of requests. 9) I want a correct recognition of ASN for gray IP - 10.137.128.1 (10.137.128.1) [AS ???] 10) I want a correct ASN recognition for some other IP - 185.1.50.68 (185.1.50.68) [AS ???] 12.581 ms -- Vladislav V. Prodan System & Network Administrator support.od.ua
Hi Steve & Vladislav, First off, thank you for sharing your hard work Steve. Global Traceroute is yet another tool showing the potential of the Atlas project. Are you using your own credits so that others may run these traceroutes? Thank you for your detailed review Vladislav. These are great suggestions. I support all of the recommendations you listed. Steve, is there interest in providing an open source version of this tool so that we may help make these modifications and enhancements? thank you, Graham Graham Nelson-Zutter CTO, Co-founder CloudPBX Inc. 204-1350 Burrard Street Vancouver, BC V6Z 0C2 +1 604 638 3848 ext 102 +1 604 674 7370 fax On Mon, Jul 16, 2018 at 1:49 PM, Vladislav V. Prodan <admin@support.od.ua> wrote:
Hello.
Thank you for your work.
I will summarize my wishes:
1) After clicking the "Submit" button, the picture on the page should be shown, that the request is coming or the text "Loading ....", so that the user realizes that the request is not fast and did not hurry to leave the page.
2) If there is only one probes in the selected ASN, then after selecting ASN, this probe should also be selected.
3) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178 the top fields of sample #19178 are automatically filled.
4) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top fields of sample #19178 were automatically filled, in "Target Address" the value 1.1.1.1 was set and the request for construction trails.
5) It would be desirable that when https request https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly take a probe from the selected location (UK), automatically fill the top fields of this sample, the "Target Address" was exposed value 1.1.1.1 and automatically sent a request to build the route.
6) I want to work correctly in the console programs curl, lynx and wget.
7) Notes at the end of the route that "Target Address" is anycast address, especially for IP facebook, google, youtube and cloudflare.
8) reCAPTCHA is certainly good against abuse, but is more accountable limits on the number of requests. It is possible, after authorization through Google or facebook, to raise the limits of requests.
9) I want a correct recognition of ASN for gray IP - 10.137.128.1 (10.137.128.1) [AS ???]
10) I want a correct ASN recognition for some other IP - 185.1.50.68 (185.1.50.68) [AS ???] 12.581 ms
-- Vladislav V. Prodan System & Network Administrator support.od.ua
On Jul 16, 2018, at 1:49 PM, Vladislav V. Prodan <admin@support.od.ua> wrote:
Hello.
Thank you for your work.
Thanks for the feedback!
I will summarize my wishes:
1) After clicking the "Submit" button, the picture on the page should be shown, that the request is coming or the text "Loading ....", so that the user realizes that the request is not fast and did not hurry to leave the page.
Agreed. This is on my to do list.
2) If there is only one probes in the selected ASN, then after selecting ASN, this probe should also be selected.
This sounds like a good idea. I’ll work on it.
3) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178 the top fields of sample #19178 are automatically filled.
4) It would be desirable, that at https request https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top fields of sample #19178 were automatically filled, in "Target Address" the value 1.1.1.1 was set and the request for construction trails.
5) It would be desirable that when https request https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly take a probe from the selected location (UK), automatically fill the top fields of this sample, the "Target Address" was exposed value 1.1.1.1 and automatically sent a request to build the route.
6) I want to work correctly in the console programs curl, lynx and wget.
I’m curious about the use case for this. Using the Atlas API, if you already know the probe ID, you do the trace route with two http transactions. The first one creates the measurement and returns a JSON containing a measurement ID. The second, 30 seconds to a minute later (thus the slowness of the web app to return results) sends the measurement ID and retrieves a JSON containing the results. What I’m adding is: - making it easier to find the right probes - turning two requests into one - supplying Atlas credits to pay for the traceroute - reformatting the JSON output into a traditional text-based traceroute output, which is easier for humans to read but maybe less useful if you’re generating the traceroutes from a machine. Are you looking for a faster way to do manual requests and get human readable output, trying to point an automated system at it, or some hybrid of the two? And if automated, is the human-readable output ideal, or would you be better off dealing with something a more machine readable format?
7) Notes at the end of the route that "Target Address" is anycast address, especially for IP facebook, google, youtube and cloudflare.
I’m curious about the use case again. Also, is there a good source for that data, or would this be adding one at a time as I discover them?
8) reCAPTCHA is certainly good against abuse, but is more accountable limits on the number of requests. It is possible, after authorization through Google or facebook, to raise the limits of requests.
This is largely an issue of resources. Thanks to a generous donor, I have enough credits for more than a million traceroutes. If I run through that due to human users, that will mean this is far more successful than I expect it to be, and there should be no problem either getting more donated, or coming up with a revenue model to buy them through Atlas sponsorship. But if I open it up for machine-generated measurements, it wouldn’t be that difficult for a single user to run through a million measurements. So, I’m certainly happy to accommodate measurement by machine or in mass quantities, but need to figure out how to make it sustainable. I have a few models in mind for that, but again it largely depends on the use cases.
9) I want a correct recognition of ASN for gray IP - 10.137.128.1 (10.137.128.1) [AS ???]
10) I want a correct ASN recognition for some other IP - 185.1.50.68 (185.1.50.68) [AS ???] 12.581 ms
The IP address to ASN mapping is coming from MaxMind’s GeoLite2 ASN database. Putting in an override for RFC1918 would be pretty easy. Other corrections should go through MaxMind — it will fix a lot more than just this, and I don’t think it’s scalable for me to track every error in MaxMind. Thanks again for the feedback. It’s really useful. -Steve
On Mon, Jul 16, 2018 at 11:49:44PM +0300, Vladislav V. Prodan <admin@support.od.ua> wrote a message of 50 lines which said:
6) I want to work correctly in the console programs curl, lynx and wget.
Why? If you're a command-line fan like me, why not using the regular programs using the API? % blaeu-traceroute -r 1 -c BD --format 2001:67c:370:1998:9819:4f92:d0c0:e94d Measurement #15260300 Traceroute 2001:67c:370:1998:9819:4f92:d0c0:e94d from BD uses 1 probes 1 probes reported Test #15260300 done at 2018-07-17T17:10:40Z From: 2403:4000:1::f 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD Source address: 2403:4000:1::f Probe ID: 12148 1 2403:4000:1::1 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD [0.535, 0.572, 0.539] 2 2403:4000:0:2::1 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD [0.95, 1.024, 0.898] 3 2403:9300:80:7::1 58587 FIBERATHOME-BD Fiber@Home Limited, BD [1.353, 1.351, 1.35] 4 2403:9300:0:8::3d 58587 FIBERATHOME-BD Fiber@Home Limited, BD [1.71, 1.56, 1.931] 5 2001:5a0:2300:300::9 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [52.887, 52.6, 52.654] 6 2001:5a0:2300:300::15 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [179.184, 179.201, 183.813] 7 2001:5a0:2000:500::1 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [176.36, 176.342, 176.36] 8 2001:5a0:2000:500::2e 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [294.366, 292.972, 293.035] 9 2001:5a0:4500:100::9 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [294.013, 294.865, 293.539] 10 2001:5a0:12:100::19 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [287.969, 287.927, 288.095] 11 2001:5a0:12:100::72 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [288.075, 287.996, 287.941] 12 2001:5a0:3900::2 6453 AS6453 - TATA COMMUNICATIONS (AMERICA) INC, US [297.65, 297.437, 297.388] 13 2001:56b:a002:f::3 852 ASN852 - TELUS Communications Inc., CA [310.554, 309.815, 309.328] 14 2001:56b:8000:101::10 852 ASN852 - TELUS Communications Inc., CA [320.198, 320.096, 320.565] 15 2001:67c:370:1998:9819:4f92:d0c0:e94d 56554 IETF-MEETING IETF Meeting Network, CH [403.806, 404.518, 394.054]
2018-07-17 20:11 GMT+03:00 Stephane Bortzmeyer <bortzmeyer@nic.fr>:
On Mon, Jul 16, 2018 at 11:49:44PM +0300, Vladislav V. Prodan <admin@support.od.ua> wrote a message of 50 lines which said:
6) I want to work correctly in the console programs curl, lynx and wget.
Why?
Firstly, your utility requires API-keys, which have problems getting them. Customers who own AS do not know how to get these keys or went too long to explain what and what they are for. Therefore, it is easier and faster for me, a freelancer, to use public shareware services. Secondly, the size of the package files. # pkg install net/py-ripe.atlas.tools Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 33 package(s) will be affected (of 0 checked): New packages to be INSTALLED: ... Number of packages to be installed: 33 The process will require 124 MiB more space. While the biggest utility is lynx has a size of 5.43MiB
If you're a command-line fan like me, why not using the regular programs using the API?
Utilities for simplicity and compactness will be available, comparable to mtr, then we will use them. In the meantime, mtr, winmtr, whois, telnet, dig and public LG are the basic tools for measurements.
% blaeu-traceroute -r 1 -c BD --format 2001:67c:370:1998:9819:4f92:d0c0:e94d Measurement #15260300 Traceroute 2001:67c:370:1998:9819:4f92:d0c0:e94d from BD uses 1 probes 1 probes reported Test #15260300 done at 2018-07-17T17:10:40Z From: 2403:4000:1::f 24122 BDCOM-BD-AS-AP BDCOM Online Limited, BD Source address: 2403:4000:1::f Probe ID: 12148
-- Vladislav V. Prodan System & Network Administrator support.od.ua
On Tue, Jul 17, 2018 at 08:58:15PM +0300, Vladislav V. Prodan <admin@support.od.ua> wrote a message of 57 lines which said:
Firstly, your utility requires API-keys, which have problems getting them.
Fair enough. On the other hand, this means that the Web site needs credits and anonymous Web clients can eat them at will, so it may not be sustainable.
# pkg install net/py-ripe.atlas.tools ... The process will require 124 MiB more space.
While the biggest utility is lynx has a size of 5.43MiB
Well, Blaeu <https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-off-measurements-with-blaeu> may be smaller but, anyway, is 124 MiB really important (and many packages are shared with other stuff), these days?
Steve, Thank you very much for making this tool. It's very encouraging from our (ie. the Atlas team's) point of view to see people making useful tools based on the network. I encourage you to continue your work, perhaps even collaborate with others in an open source fashion to scale up, and also let us -- the Atlas team -- know if we can be of assistance. Regards, Robert On 2018-07-16 14:15, Steve Gibbard wrote:
I wrote front-end to traceroute from the RIPE Atlas probes. It looks like a standard looking glass — you select a probe by location and AS number, enter a destination, and it does a traceroute. It’s on the web at https://www.globaltraceroute.com. If this looks useful, please check it out and tell me what you think.
One of the things I've found frustrating when troubleshooting routing problems was the lack of information about inbound paths. Various measurement systems would tell me when performance was bad. Traceroutes from my own network would tell me what path traffic to a destination was taking outbound. Flow systems would tell me what interface inbound traffic was coming in on, and sometimes what peer it was coming through. But determining the full path inbound traffic was taking — why users of some ISP in Asia were having their traffic show up at one of my POPs in Europe, for instance, was much more difficult.
I’ve been using looking glasses and commercial performance monitoring systems that allow traceroutes from their probes, but those often weren’t where the end users were. RIPE Atlas did have probes where a lot of my end users were, so I started configuring one time measurements on RIPE Atlas whenever I needed a traceroute from a simulated end user. But finding a suitable probe and configuring the measurement was too cumbersome to do when I wasn’t pretty desperate. This is my attempt to solve that problem.
Thanks, Steve
participants (6)
-
Graham Nelson-Zutter -
Robert Kisteleki -
scg＠gibbard.org -
Stephane Bortzmeyer -
Steve Gibbard
-
Vladislav V. Prodan