Hmm, I dont feel like this is a good use of traceroute.
Its already kind of nebulous, what with MPLS no-decrement-ttl and tunneling protocols.
Add to that geo ip is often fantastically wrong. Especially if the ISP has no need for it for its own troubleshooting. They might not go out of their way to update geoip correctly, relying on the routers hostname for information.
Blowing it up to display it on a map and pretend like the data returned from traceroute is aligned with reality rubs me the wrong way.
I work for IPinfo and provided the data for it. The original intention for the project was to identify data center locations. The original idea of the project came from https://stefansundin.github.io/traceroute-mapper/. I reworked it and then OP added a lot of bells and whistles. For my day-to-day work, I still use my version.
I manage approximately 1,200 PoPs that are part of IPinfo's ProbeNet platform, which is used to generate our internet measurement data. We, in turn, use this data to produce the IP geolocation data you utilize. The issue is that the servers we manage can be moved to different locations or not be in the advertised locations. We operate these PoPs across 500 cities.
Whenever the PoP fails to meet certain physical location checks, I run basic diagnostic tests to determine where the server is located and where it is not. Aside from running ping and traceroute operations to the target servers, I can run traceroutes to certain IP addresses whose paths I am familiar with. A traceroute visualizer provides a visual interface, information on the ASN, the geolocation, and the time measurements. This provides an intuitive view of where the server "could not be" located rather than could be located. We use several techniques to run basic diagnostic tests. This traceroute visualizer isn't an official test of IPinfo; it is something I vibe-coded together. There are far better internal tools, such as running ping and traceroutes across all of our ~1,200 servers simultaneously.
It is a network diagnostic tool. I think based on your comment, it is not just a tool, it is more of an abstraction of a tool! But it is somewhat useful I thinkl.
I am happy to hear your thoughts. I manage these servers and we are trying our best to improve our data consistently. So, any ideas or even random thoughts you might have can help us improve.
The aim was to scratch an itch which was to try to visually see what is going on with my packets when going to a given website. Of course it's not perfectly reliable (due to geoip loc or hops not answering / using link IPs) nor does it claim to be.
I believe they already provided "Standard traceroute example", "Flyingroutes example (with protocol breakdown)" and "MTR example (with packet loss and timing statistics)".
I work for IPinfo. I did not know that our site was blocked by Firefox Enhanced Tracking Protection. Not sure what I can do here. The project takes the IP addresses you have provided from your traceroute and gets the information related to them from our website using a frontend HTTP call.
Enhanced Tracking Protection is using the Disconnect domain list. ipinfo.io is listed in services-relay.json and mdl-services-relay.info, which I believe makes the Disconnect.me product route requests to these domains through their proxies to prevent IP fingerprinting.
Should be noted that IPInfo doesn't get blocked with tracking protection set to "standard". Users have to set tracking protection to "strict" to run into this issue. When they do this, they get warned that this setting may break sites.
I don't think Mozilla/Disconnect will make an exception because privacy-infringement is a potential risk with a service like yours if used by malicious websites. I wouldn't put too much effort into this, the people affected by this are a fraction of a fraction of the general web audience and they've already seen a warning that websites may break because of their choice.
Love it, I'm still often surprised by how long a hop can be. e.g. I'm looking at one from France to Singapore.
If you're looking to trace to something far away when doing a demo we've got servers in ~280 cities around the world so <random large city>.wonderproxy.com works. e.g. taipei.wonderproxy.com or santiago.wonderproxy.com, berlin, newyork, etc.
auto-detected my IPv4 addy, but my tracert to google.com went over IPv6.
I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.
For IPv4, the geolocation information is quite limited (city-level) so if you live close to a major data center, you'll have a distance of 0 on the map.
Still, seeing the routes on the map is kind of fun. I don't think it provides anything useful in terms of troubleshooting that mtr doesn't provide already, but there's a fun novelty to see your traces on a map like in a 90s hacker movie.
In principle, if you ping from multiple known interfaces and paths, you can infer probable location, with confidence going up with the more known points of reference you have. You can do a little calculation and triangulation based off of latency and responsive known targets traversing the same path as the endpoint you're trying to geolocate, and get a very high confidence result for zip code, city, or maybe even 3-4 block radius, if there are a bunch of ISPs in the region. Even with only 3-4 ISPs, by sourcing from different directions along different networks you can get more resolution in the final estimated radius for geolocation.
You can even use a whole bunch of fuzzy rough estimations for endpoints in a region to get progressive increments in resolution until you're happy with a precise location. You can also use educated guesses about the type of router at each hop, then use response times and behaviors for pings coming from different directions at different times. If you can arrange to traverse a node and pump traffic over it, you can use behavior with different types of traffic to elicit the type of router, the policies in place, and so on.
It's a good idea to turn off responses to pings and minimize the amount of information available, even if it seems mostly harmless. The amount of information you can get from the public internet, just in terms of basic network utility functions and behaviors, is probably a lot more than most people ever consider.
You could do the long list of things you listed. Has anyone done a high-quality implementation of those things? And checked the results? I’d be interested in seeing that.
Yes, traceroute isn't ping. I was describing how you might get high quality geolocation for ip addresses, which in turn could be used in conjunction with traceroute and other tools to map things with a high degree of confidence, since they were bringing up how bad geolocation usually is.
As far as I know, there aren't any public tools which do what I described - it's a weekend's worth of scripting up a proof of concept (or an hour, with AI) and it'd be questionable for open source. You might run afoul of various regulations around the world, and you'd probably get hate mail and legal challenges trying to host something like it. Github and Sourceforge would probably not be willing to hear out any challenges or takedown requests over it.
All that to say, it's probably too much of a hassle to try to make a big open implementation with it, especially since AI can whip it up fairly trivially and even give you a fancy OSM integrated dashboard for whatever you might want to use it for.
That only really works if ISP routing is drastically different than it usually is. When I was on DSL at my current house, the IP range available covers basically the whole multi-county metro area; all paths go through the PPPoE concentrator in a single location. You could maybe make a distance estimate from the concentrator, but there's no way to get more information than that.
I think the cable company is a bit more refined, I see cities in traceroutes that don't make sense for the whole metro area to route through, so it's likely that you can determine county, and possibly more specific. But you won't get any useful information from trying to ping outside resources; ISP networks all interconnect at the local internet exchange (or there about), when I had access to a DSL, a cable, and a local fiber ISP all in the same city, pings all went back to the IX. Maybe if you have a lot of presence in an ISP, you can gather a bit more data about users in that ISP, but it won't help you gather data about users on other ISPs.
Disabling pings is nice and all, but if you exchange any traffic, round trip times are pretty easy to gather from that. Delayed ack ads a bit of a challenge, but not much.
Of course, many isps offer geofeeds for their IPs. That's pretty reasonable to use if offered.
Neat project! The instant map visualization makes it much easier to grok what's happening on the wire compared to just reading out hops and ping times.
Nice idea, but shoddy implementation, it does not properly detect the starting point based on my IP and the route shown is not matching what I know about the physical topology of the network in this region. You probably should ask infrastructure providers if they are willing to give you access to the endpoint and physical routes rather than just to use geolocation for IP addresses resulting in errors and unrealistic routes. There are only a couple of players in that space, and I think they sell the data. Otoh, given the current situation with attacks on infrastructure they might not be willing to accommodate a party without a strict need.
Would you mind sharing the link (after removing the data you don't want to share)? I'm using IPInfo's data and each hop IP is the end of a segment so it's normal it doesn't follow your expected topology (to which we can add the limitations of traceroute)
Not much point, really, it only detects one hop correctly the rest is garbage. So all that's left is my home IP address, and that gets placed well over a 100 km from where I actually am. I don't mind :)
I work for IPinfo and we provided the data for the project. I would really appreciate your insight on this.
We run ping and traceroute operations from 1,200 servers across the world to every (within reason) IP address out there. So, we have ping RTT and traceroute data history of these measurements.
Considering the physical network topology does not match the physical network topology, we would love to hear your thoughts.
Unrouted IP addresses do not appear on the internet traffic, and we have limited network data for them.
If you can share your traceroute output and obfuscate as much data as possible, we will be happy to investigate and share feedback.
I would not expect the latency for handling ttl expired packets to be very strongly correlated with the latency for forwarded traffic, unless exceptional conditions.
Traceroute isn't real, or: Whoops! Everyone Was Wrong Forever: https://gekk.info/articles/traceroute.htm
Hadn't seen this before, very nice read, thank you!
Hmm, I dont feel like this is a good use of traceroute.
Its already kind of nebulous, what with MPLS no-decrement-ttl and tunneling protocols.
Add to that geo ip is often fantastically wrong. Especially if the ISP has no need for it for its own troubleshooting. They might not go out of their way to update geoip correctly, relying on the routers hostname for information.
Blowing it up to display it on a map and pretend like the data returned from traceroute is aligned with reality rubs me the wrong way.
I work for IPinfo and provided the data for it. The original intention for the project was to identify data center locations. The original idea of the project came from https://stefansundin.github.io/traceroute-mapper/. I reworked it and then OP added a lot of bells and whistles. For my day-to-day work, I still use my version.
I manage approximately 1,200 PoPs that are part of IPinfo's ProbeNet platform, which is used to generate our internet measurement data. We, in turn, use this data to produce the IP geolocation data you utilize. The issue is that the servers we manage can be moved to different locations or not be in the advertised locations. We operate these PoPs across 500 cities.
Whenever the PoP fails to meet certain physical location checks, I run basic diagnostic tests to determine where the server is located and where it is not. Aside from running ping and traceroute operations to the target servers, I can run traceroutes to certain IP addresses whose paths I am familiar with. A traceroute visualizer provides a visual interface, information on the ASN, the geolocation, and the time measurements. This provides an intuitive view of where the server "could not be" located rather than could be located. We use several techniques to run basic diagnostic tests. This traceroute visualizer isn't an official test of IPinfo; it is something I vibe-coded together. There are far better internal tools, such as running ping and traceroutes across all of our ~1,200 servers simultaneously.
It is a network diagnostic tool. I think based on your comment, it is not just a tool, it is more of an abstraction of a tool! But it is somewhat useful I thinkl.
I am happy to hear your thoughts. I manage these servers and we are trying our best to improve our data consistently. So, any ideas or even random thoughts you might have can help us improve.
The aim was to scratch an itch which was to try to visually see what is going on with my packets when going to a given website. Of course it's not perfectly reliable (due to geoip loc or hops not answering / using link IPs) nor does it claim to be.
I'm on my phone, maybe your site would benefit having sample data available to showcase what it can do?
I believe they already provided "Standard traceroute example", "Flyingroutes example (with protocol breakdown)" and "MTR example (with packet loss and timing statistics)".
But you have to copy those examples from another spot in the post and paste it into the box that is already populated with placeholder information.
And for whatever reason, copy and paste on the page is flakey and required several retries on my iPhone running iOS 26.
I added a Load sample button so you can test it easily
The calls to the ipinfo.io API are blocked by Firefox Enhanced Tracking Protection. No results for Location or ISP without turning that off.
I work for IPinfo. I did not know that our site was blocked by Firefox Enhanced Tracking Protection. Not sure what I can do here. The project takes the IP addresses you have provided from your traceroute and gets the information related to them from our website using a frontend HTTP call.
Enhanced Tracking Protection is using the Disconnect domain list. ipinfo.io is listed in services-relay.json and mdl-services-relay.info, which I believe makes the Disconnect.me product route requests to these domains through their proxies to prevent IP fingerprinting.
Should be noted that IPInfo doesn't get blocked with tracking protection set to "standard". Users have to set tracking protection to "strict" to run into this issue. When they do this, they get warned that this setting may break sites.
I don't think Mozilla/Disconnect will make an exception because privacy-infringement is a potential risk with a service like yours if used by malicious websites. I wouldn't put too much effort into this, the people affected by this are a fraction of a fraction of the general web audience and they've already seen a warning that websites may break because of their choice.
Thank you very much for looking into it. I really appreciate it! I agree with you. I understand the point clearly.
The site is flagged as "phishing" by Palo Alto - submitted change request.
edit: They updated from phishing to "computer and internet info" , no longer blocked.
Thank you very much! I work for IPinfo. I am not super familiar with the platform, so it went under my radar. I appreciate the correction.
Love it, I'm still often surprised by how long a hop can be. e.g. I'm looking at one from France to Singapore.
If you're looking to trace to something far away when doing a demo we've got servers in ~280 cities around the world so <random large city>.wonderproxy.com works. e.g. taipei.wonderproxy.com or santiago.wonderproxy.com, berlin, newyork, etc.
Happy you like it!
didn't work for me at all.
auto-detected my IPv4 addy, but my tracert to google.com went over IPv6.
I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.
I don't think it can parse IPv6 traceroutes.
For IPv4, the geolocation information is quite limited (city-level) so if you live close to a major data center, you'll have a distance of 0 on the map.
Still, seeing the routes on the map is kind of fun. I don't think it provides anything useful in terms of troubleshooting that mtr doesn't provide already, but there's a fun novelty to see your traces on a map like in a 90s hacker movie.
In principle, if you ping from multiple known interfaces and paths, you can infer probable location, with confidence going up with the more known points of reference you have. You can do a little calculation and triangulation based off of latency and responsive known targets traversing the same path as the endpoint you're trying to geolocate, and get a very high confidence result for zip code, city, or maybe even 3-4 block radius, if there are a bunch of ISPs in the region. Even with only 3-4 ISPs, by sourcing from different directions along different networks you can get more resolution in the final estimated radius for geolocation.
You can even use a whole bunch of fuzzy rough estimations for endpoints in a region to get progressive increments in resolution until you're happy with a precise location. You can also use educated guesses about the type of router at each hop, then use response times and behaviors for pings coming from different directions at different times. If you can arrange to traverse a node and pump traffic over it, you can use behavior with different types of traffic to elicit the type of router, the policies in place, and so on.
It's a good idea to turn off responses to pings and minimize the amount of information available, even if it seems mostly harmless. The amount of information you can get from the public internet, just in terms of basic network utility functions and behaviors, is probably a lot more than most people ever consider.
Traceroute isn’t “ping,” it’s exploiting TTL manipulation to generate ICMP unreachables.
You could do the long list of things you listed. Has anyone done a high-quality implementation of those things? And checked the results? I’d be interested in seeing that.
Yes, traceroute isn't ping. I was describing how you might get high quality geolocation for ip addresses, which in turn could be used in conjunction with traceroute and other tools to map things with a high degree of confidence, since they were bringing up how bad geolocation usually is.
As far as I know, there aren't any public tools which do what I described - it's a weekend's worth of scripting up a proof of concept (or an hour, with AI) and it'd be questionable for open source. You might run afoul of various regulations around the world, and you'd probably get hate mail and legal challenges trying to host something like it. Github and Sourceforge would probably not be willing to hear out any challenges or takedown requests over it.
All that to say, it's probably too much of a hassle to try to make a big open implementation with it, especially since AI can whip it up fairly trivially and even give you a fancy OSM integrated dashboard for whatever you might want to use it for.
That only really works if ISP routing is drastically different than it usually is. When I was on DSL at my current house, the IP range available covers basically the whole multi-county metro area; all paths go through the PPPoE concentrator in a single location. You could maybe make a distance estimate from the concentrator, but there's no way to get more information than that.
I think the cable company is a bit more refined, I see cities in traceroutes that don't make sense for the whole metro area to route through, so it's likely that you can determine county, and possibly more specific. But you won't get any useful information from trying to ping outside resources; ISP networks all interconnect at the local internet exchange (or there about), when I had access to a DSL, a cable, and a local fiber ISP all in the same city, pings all went back to the IX. Maybe if you have a lot of presence in an ISP, you can gather a bit more data about users in that ISP, but it won't help you gather data about users on other ISPs.
Disabling pings is nice and all, but if you exchange any traffic, round trip times are pretty easy to gather from that. Delayed ack ads a bit of a challenge, but not much.
Of course, many isps offer geofeeds for their IPs. That's pretty reasonable to use if offered.
I don't think it works with Windows tracert output
edit: edited my windows traceroute to match the linux format and it works nicely. great tool.
You can now use your windows tracert outputs directly!
I'm not sure if this worked as intended when tracert to google.com I get my IP, skips 13 hops, then 10 unknowns?
I didn't add support for tracert. Will do that and report back!
Done! Feel free to use tracert outputs now!
This is pretty sweet, nice job. i dig the mapping visualization.
Much appreciated!
Neat project! The instant map visualization makes it much easier to grok what's happening on the wire compared to just reading out hops and ping times.
Thanks!
This is great! Really loved the tool, I would probably position the map over the table tbh..
Thanks for the feedback! It's true that the first's job is to visualize - we can read the details after
Added :)
Nice idea, but shoddy implementation, it does not properly detect the starting point based on my IP and the route shown is not matching what I know about the physical topology of the network in this region. You probably should ask infrastructure providers if they are willing to give you access to the endpoint and physical routes rather than just to use geolocation for IP addresses resulting in errors and unrealistic routes. There are only a couple of players in that space, and I think they sell the data. Otoh, given the current situation with attacks on infrastructure they might not be willing to accommodate a party without a strict need.
Would you mind sharing the link (after removing the data you don't want to share)? I'm using IPInfo's data and each hop IP is the end of a segment so it's normal it doesn't follow your expected topology (to which we can add the limitations of traceroute)
Not much point, really, it only detects one hop correctly the rest is garbage. So all that's left is my home IP address, and that gets placed well over a 100 km from where I actually am. I don't mind :)
I work for IPinfo and we provided the data for the project. I would really appreciate your insight on this.
We run ping and traceroute operations from 1,200 servers across the world to every (within reason) IP address out there. So, we have ping RTT and traceroute data history of these measurements.
Considering the physical network topology does not match the physical network topology, we would love to hear your thoughts.
Unrouted IP addresses do not appear on the internet traffic, and we have limited network data for them.
If you can share your traceroute output and obfuscate as much data as possible, we will be happy to investigate and share feedback.
I love more tooling and attention given to latency . Throughput gets the attention but latency is what drives a high quality experience
I would not expect the latency for handling ttl expired packets to be very strongly correlated with the latency for forwarded traffic, unless exceptional conditions.
you're confusing noise for lack of correlation