Speedy Internet, Gone Without a Trace
When ever I try to go to a certain website, it always seems slow, especially photos and such. Other sites seem to work okay, but not this one. How can I look into this?
Good question. We have to make some assumptions that are sometimes not accurate for massive Content Delivery Network (CDN) systems, but normally they’re not slow.
The first step is to get a network trace to the remote system. Take the part of the web address after the first two slashes and the next slash, this is the host name. For example: from “http://sc.edu/athletics/“ the host name is “sc.edu”. Open a command window and enter tracert followed by a space and the host name, again using our example above, you’d type “tracert sc.edu”. Then press enter. You should, over the course of 20 to 50 seconds, get something like this:
Each line is a “hop” along the network to your destination. The first three columns (after the hop number column) represent three attempts to get a response from that hop. An asterisk in a column means that no response was given by that hop on that attempt. If the numbers are wildly different, it means that things are not consistent when you did your test. You can try again to see if things stabilize, but they may not.
The first hop above is my Residential Gateway (or homeportal). Then there’s the first router on the other end of my connection to AT&T. You should expect to see about 15-25 ms on this hop. If you see a lot more, it could indicate that your connection is the issue, probably because it’s busy carrying other traffic, especially outgoing traffic.
Anyway, when there are three stars on one line that means that the device at that hop never returned a response to the route probe. This can be for many reasons: (1) it’s configured to ignore/drop ICMP packets used to do this probe entirely, (2) it’s configured to not respond to errors on ICMP packets (and errors are how the route probe works), (3) it’s configured to respond only when it’s not very busy, and it’s busy, or (4) there’s some actual network issue.
Note that hop 7 didn’t respond to three probes. Is there a network issue there? There probably is not, because hop 7 passed all three probes to hop 8 and hop 9 (or they wouldn’t have been able to respond). So, let’s just dismiss that. Now hop 10 didn’t respond, and neither did anything after it (I canceled the probe after hop 12 had missed a probe attempt, otherwise it would have tried out to hop 30). From this sample, it looks like hop 9 is as far as we can go in our route map. So, is hop 9 part of the AT&T network or maybe some interconnect? Let’s ask ARIN, the assigner of IP addresses in the Americas. I went to arin.net and filled the IP address of hop 9 in the “SEARCH WHOIS” box, as shown below and clicked the button beside it
This resulted in this "https://prod-content-care-community-cdn.sprinklr.com/d80f176d-2bd5-487b-b539-b24b3ede5ed6/SpeedyInternetGoneWithoutaTrac-c779d06f-4c25-4fd6-b439-5652bec43837-481406086" alt="20150924 jeffermc 3.png" title="20150924 jeffermc 3.png" border="0" />
Ah, the University of South Carolina (which is what sc.edu is the domain name for) owns this address. That means that this is probably the gateway router for the University and it drops ICMP (ping/tracert) packets at the door. But, it also means that we got this far, and our latency is still less than 50 milliseconds, which is decent. This shows that if there is any problem, it’s probably inside the USC network.
Let’s say we had a little different result in our tracert:
On this traceroute, I started it right as a speedtest started testing the upstream connection stream. Because speedtest deliberately fills the upstream beyond capacity (to find the capacity), the ping packets were delayed, taking over 200 ms. Note the effect by hop 4 as the speed test ends transmitting data. The trip times drop. Note that these times given are each for the total round trip from your system doing the tracert to the hop reporting, and for the network conditions during that test. If things are changing, the numbers may try to tell you funny things. Repeat your tests when tracking things down to be sure you have a complete picture. So, if your cell phone is backing up the pictures you took over your Wi-Fi to “the cloud,” it can slow down your network connection for everyone in the home. This can happen for a “really fast” connection, but not for as long (because the transmission will take less time). Note that I tried this exact same trick when speedtest was running the downstream, but the effects were not really noticeable. Upstream congestion is much more of a problem than down.
One last trace for now:
In this route trace, the latency jumps by a quarter second between hop 5 and 6, and stays there at hops 8 and 9. This means there’s likely some issue between hop 5 and 6 or at hop 6. So… what part of the network were we navigating at that point? A WHOIS search at ARIN (just like before) now gives “AT&T Services, Inc. (ATTSE-Z)”, so this time the issue seems to be in AT&T’s network. If the problem lasts more than a few minutes, you can try reporting it to AT&T’s U-verse Technical Support group and see if they can tell you anything.
There are more things you can do to go further in depth, especially with intermittent issues, but this is enough to give you the basics of network tracing to see where the delays may be occurring.