How to Read a Traceroute
This guide will teach you how to read a traceroute to identify potential connection issues or packet loss
Gathering traceroutes
To get a traceroute, open command prompt in Windows or Terminal on OSX and run the following. The first argument takes either a domain or IP address.
Windows
Linux/OSX
Let the traceroute run for 1-2 minutes before assessing
Reading the traceroute
Now that you have your traceroute, you will see something that looks like this.
You will notice that by hop 14 we have 400ms+. Could this be TCPShield related? We will analyze this traceroute closely to see what might be causing this.
Typical traceroutes are formatted like so:
Let's outline what each of these mean.
Traceroutes are read in-order starting from the first hop (at this point packets usually haven't exited the source network to the public internet yet), and the destination hop. Most hostnames you will see in a traceroute will contain information that may outline what location that router or switch is located, for example ae7.cr7-chi1.ip4.gtt.net indicates a router in Chicago belonging to GTT, six-sea.netarch.akamai.com is an endpoint in Seattle belonging to Akamai (located in SIX - Seattle Internet Exchange), and so on.
Sometimes you may never reach the destination hop, like in the example above. This is completely normal for TCPShield, as we disable all protocols except TCP 25565/443/80 across our edge nodes.
Lets look at the above trace a bit more closely.
The first 3 hops contain critical information here that will help us determine the cause for the high latency. You will see each of the 3 probes here have varying degrees of latency. Starting at the first hop, one of the probes has 302.809ms. This definitely isn't expected as the first hop is usually your home router or switch in a residential network - something that should be below 5ms ideally for all probes on that hop. Indeed, we have 10ms shown on one of the probes, however the other 2 have latencies in the triple digits which signify an unstable connection.
For context, I was running this traceroute over WiFi in an area with many connected clients. We can also see the same effects shown in the 3rd hop. During this point, our packets still have not left the internal network to the outside world yet - so as a result of our unstable connection to the WiFi router, this has introduced propagation delay to the remainder of the traceroute. As mentioned previously, packets are routed on the internet in a hop-by-hop basis. If one of the hops in that path experiences high latency or congestion, this will impact the quality of service for the remainder of the trace. In networking, a chain (or path in this case) is only as strong as its weakest link.
Any hops where you see 10.0.0.0/8, 172.16.0.0/16, or 192.168.0.0/16 are RFC1918 addresses, which are reserved for internal networks. If you see IP addresses in these CIDRs, it usually signifies packets have not exited to the public internet yet. Any high latency within these hops typically propagate to the remainder of the trace.
This now gives us more clues as to what is happening at hop 14 - the last hop we could observe before hitting TCPShield's edge nodes and thus not being able to proceed further (as we block ICMP across our edge).
BHS in this case indicates Beauharnois - our North American proxy location, and VAC indicates the mitigation infrastructure utilized at this facility. During normal circumstance (i.e. when connected over ethernet), the computer used to perform this traceroute typically experiences 60ms to this VAC hop. Do you remember the 302.809ms probe we saw on the first hop of our trace? Our unstable connection to our internal network has unfortunately propagated its way to the rest of our Traceroute, resulting in the high latency on hop 14 - therefore adding ~300ms to what would should normally be within the 60-70ms range. Networks are only as stable as the weakest link - and in our case, our weakest link is indeed our internal (home) network.
The BGP (border gateway protocol) is the system that glues the internet together, and is responsible for making routing decisions between switches and routers on the internet. In normal circumstances, BGP will route around these problems automatically when high latency or packet loss becomes and issue between major PoPs (point of presences) on the internet. However in our case, there really isn't anything to route around because we haven't routed anywhere yet - the high latency is present within our LAN itself, and our only solution at this point would be to diagnose why this could be happening.
Diagnosing propagation delay
Since our high latency occurred within our internal network itself - it would be a good idea to determine why this is happening. After all, WiFi isn't totally stable from a jitter standpoint, especially considering this trace was performed with many other clients connected - and presumably other appliances or electronic equipment interfering as well. For residential connections, you should first try and see if the high latency is still present when performing a traceroute over Ethernet, which is not prone to the inherent pitfalls introduced with Wifi.
If the high latency still occurs over Ethernet, the most probable scenario is a congestion issue within the ISP your player(s) are using itself. During high traffic periods of the day, sometimes an ISP's downstream link to its distribution routers may be overwhelmed, and thus forwarding and propagation delays will be an inherent issue that cannot be solved without contacting the ISP's network engineers to further diagnose the issue.
Last updated
