> This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
Dealt with something similar 25 years ago as a new guy at a large bank.
They had a DS3 to AT&T for Internet and a T1 to Sprint for 'back-up' in case the primary went down. Same AS, but 75% of the Internet traffic perferred the Sprint return route.
Our 'network guy' couldn't figure out why everyone in this company (100k employees) was experiencing worse than dial-up performance at their desks. Took about 10 minutes to see what the issue was (using reverse traceroute from a looking glass server out there somewhere).
As soon as we fixed that, ran into the next problem. Dude built a caching proxy server on a Sun e4500 with ONE disk.
Anecdotally, I've run a bunch of traceroutes and reverse traceroutes to different locations and they tend to follow the same AS paths — although sometimes the traceroute will surface more routing through your ISP (especially from college networks). In general you are correct, though, and I would love to explain more about hot-potato vs. cold-potato (and other interesting routing decisions) in the future. Either way, the results the reverse traceroute provides are good enough for the purposes of explaining the internet, IMO!
FYI what you described is hot-potato routing: each AS gets rid of it as soon as possible.
You may think this is unfair, and yes, it is, but it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
> "You may have noticed that the traceroute progressively loads in lines above the bottom line. Web pages can only load forward. Since I didn’t want to use any JavaScript, I did the hackiest thing possible: every time I update the traceroute display, I embed a CSS block that hides the previous iteration! Since browsers render CSS as the page is loading, this made it look like the traceroute was being edited over time."
> Seems like this hit the Hacker News front page again, and the server's having some trouble pinging all of you. Feel free to read the article, but if you want to see your tracereoute you might need to bookmark and check back tomorrow :)
Hmm, after several seconds it gave up and displayed raw markup ... I'm not sure exactly why in this case, but ...
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
It's like when your uncle squeezes you at Christmas. You're glad to see him again, but it's just a liiiitttleee... too... much... for... your... lungssss,.,.,.,
> This reverse traceroute is still helpful. The paths will be roughly the same, likely differing only in terms of which specific routers see your packet.
This is categorically incorrect. While the AS path is often the same, the actual peering points are almost always quite different. Most ASes use hot-potato routing - getting packets to the next AS at the closest peering point to the source of the traffic. (And even if cold-potato routing is used, that's still asymmetric). In addition if there are two options with the same AS-path-length hot-potato routing can lead to different AS paths. This can happen if there's two mutual transit providers between source and destination and various other situations.
(EDIT: fixed hot/cold mixup)
Dealt with something similar 25 years ago as a new guy at a large bank.
They had a DS3 to AT&T for Internet and a T1 to Sprint for 'back-up' in case the primary went down. Same AS, but 75% of the Internet traffic perferred the Sprint return route.
Our 'network guy' couldn't figure out why everyone in this company (100k employees) was experiencing worse than dial-up performance at their desks. Took about 10 minutes to see what the issue was (using reverse traceroute from a looking glass server out there somewhere).
As soon as we fixed that, ran into the next problem. Dude built a caching proxy server on a Sun e4500 with ONE disk.
Got to be a hero for a little bit lol.
Anecdotally, I've run a bunch of traceroutes and reverse traceroutes to different locations and they tend to follow the same AS paths — although sometimes the traceroute will surface more routing through your ISP (especially from college networks). In general you are correct, though, and I would love to explain more about hot-potato vs. cold-potato (and other interesting routing decisions) in the future. Either way, the results the reverse traceroute provides are good enough for the purposes of explaining the internet, IMO!
FYI what you described is hot-potato routing: each AS gets rid of it as soon as possible.
You may think this is unfair, and yes, it is, but it's also quite logical when you consider you don't know where the packet is going in the destination AS. If you have a network spanning Berlin and Hamburg and the packet is going to a different network that also spans Berlin and Hamburg, and you interconnect at both points, and you don't know which city it's actually going to, handing it off at the closest interconnect doesn't risk round-tripping it for no good reason.
ha yes thank you. I worked for a AS that mostly did cold-potato routing so grabbed the wrong term trying to describe the common case.
> "You may have noticed that the traceroute progressively loads in lines above the bottom line. Web pages can only load forward. Since I didn’t want to use any JavaScript, I did the hackiest thing possible: every time I update the traceroute display, I embed a CSS block that hides the previous iteration! Since browsers render CSS as the page is loading, this made it look like the traceroute was being edited over time."
Love this
You can also do out-of-order HTML streaming without JavaScript using declarative shadow DOM. For example:
https://lamplightdev.com/blog/2024/01/10/streaming-html-out-...
oh yeah i saw this! newer than the website though :)
This is not my beautiful website.
This is not my beautiful home-page.
There are packets at the bottom of the network stack
And you may find yourself
Behind the keyboard of a large PC
And you may find your website in a beautiful datacenter, on a beautiful server.
Typing in code you don’t understand
And if you haven't ever seen it before, run
and alsoNice! Dr. Horrible would be proud of this geeky tribute:
also
I thought this was going to play a Talking Heads song
check the html :)
letting the days go by
> Seems like this hit the Hacker News front page again, and the server's having some trouble pinging all of you. Feel free to read the article, but if you want to see your tracereoute you might need to bookmark and check back tomorrow :)
> - Lexi, Nov 7, 3:16 PM PST
somewhat better now! added a bit more concurrency. lesson learned: use tokio next time
Hmm, after several seconds it gave up and displayed raw markup ... I'm not sure exactly why in this case, but ...
One of the major infelicities of the web is that CSS is specified to ignore truncation, and there is no way to fix this. Now think about what happens if something like `display: inline-block` gets truncated before the `-`.
Doesn't work. Traceroute showed only 1 hop.
Mine too. Maybe it's CGNAT.
Read the green text
Previous Show HN: from the dev in 2023:
https://news.ycombinator.com/item?id=38531604
Doesn't seem to be working?
HN Hug of death ?
It's like when your uncle squeezes you at Christmas. You're glad to see him again, but it's just a liiiitttleee... too... much... for... your... lungssss,.,.,.,
Same as it ever was.
I thought this was going to be a review of life choices
The review of life choices happens in our heads when we click this link on the main HN page.
(sigh) I'm just thinking those thoughts right now.