Quote from: Oshyan on October 14, 2018, 06:35:05 PM
I should note that not all servers in a tracert will necessarily respond to this request. I see request timeouts all the time. Heck, try cnn.com, I get a timeout on hop 8, but their server itself responds just fine and the site loads, of course.
Also, no 150ms is not terrible for overseas to US. Not great either. But it shouldn't be causing really long site load times.
- Oshyan
They should. The only reason they didn't, is they are overloaded via traffic, the packet was sent to the control brain (as apposed to data) and thus dropped because it's flagged priority (to not interfere with hardware). In that case, that hop in a traffic forwarding scenario can drop, or hang, and possibly timeout.
A firewall issue where the server just doesn't respond to this would cause the Tracert to end, and it would not note the trace being
complete but
aborted. Subsequently though a completely dead server (not just dead network wise during that tracert) would also case an aborted tracert.
However because it's complete, the packet was sent, and went through, the servers router was just having issues. These packets are sent three times consecutively. So if all three fail, but the rout is complete, it's definitely a routing issue, rather than a dead route.
This is also why high priority data centers use an actual server as a "Core" router, and often allow these low priority packets, that way if it's sent to via the control plane route, it is handled for debugging purposes. Such as gaming nodes. Physical routers have virtually no computing power and
should drop these packets when it's under load.
It's very probable that hop is hanging, and causing the slowdown when actually processing taffic data. I get straight timeout pages a lot on here, but it's not a speed issue, just network routing. I'm also not sure using CNN and high-traffic routes are good comparisons. It's likely you'd see dropped packets considering consecutive traffic to that destination.