0

I have recently be plagued by low download speeds from my server and was curious, so I ran a traceroute. (I have removed the end IP and the start IP).

I achieve a download speed of 220Kb/s when I am promised a speed of 30Mbps by my ISP (the server is in Canada and I am in Florida). This has not happened until recently, and I am seriously concerned that my ISP (Verizon) may be traffic shaping. Can anyone offer a valid explanation as to why this might be happening to me?

Interestingly, the traceroute from my computer to my server shows up fine with 12 hops:

 1  TEW-810DR (192.168.1.1)  1.847 ms  1.832 ms  2.714 ms
 3  * * *
 4  0.ae10.GW1.MIA19.ALTER.NET (140.222.231.83)  14.970 ms  15.094 ms  15.093 ms
 5  teliasonera-gw.customer.alter.net (152.179.236.22)  67.394 ms  67.572 ms  67.574 ms
 6  ash-bb4-link.telia.net (62.115.136.204)  94.843 ms ash-bb3-link.telia.net (62.115.141.72)  92.753 ms ash-bb4-link.telia.net (62.115.141.129)  90.262 ms
 7  nyk-bb2-link.telia.net (62.115.137.65)  92.696 ms nyk-bb2-link.telia.net (213.155.133.8)  117.651 ms nyk-bb2-link.telia.net (62.115.137.67)  90.177 ms
 8  nyk-b2-link.telia.net (213.155.130.28)  97.654 ms nyk-b2-link.telia.net (62.115.134.108)  90.165 ms nyk-b2-link.telia.net (213.155.130.30)  95.060 ms
 9  * * *
10  192.99.146.84 (192.99.146.84)  126.198 ms  124.014 ms  119.930 ms
11  bhs-3a-a9.qc.ca (198.27.73.92)  127.757 ms  127.655 ms  127.245 ms

On the other hand, the traceroute from my server to my computer shows a whopping 30 hops!

 1  192.99.6.252 (192.99.6.252)  0.703 ms  0.838 ms  0.949 ms
 2  198.27.73.95 (198.27.73.95)  341.634 ms 198.27.73.93 (198.27.73.93)  0.662 ms 198.27.73.95 (198.27.73.95)  341.673 ms
 3  * * *
 4  * * *
 5  * if-1-3.thar2.NJY-Newark.as6453.net (216.6.57.2)  25.590 ms *
 6  if-4-4.tcore2.NYY-New-York.as6453.net (66.198.111.18)  25.575 ms if-1-3.thar2.NJY-Newark.as6453.net (216.6.57.2)  25.761 ms if-4-4.tcore2.NYY-New-York.as6453.net (66.198.111.18)  25.218 ms
 7  if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46)  23.178 ms if-4-4.tcore2.NYY-New-York.as6453.net (66.198.111.18)  25.195 ms  25.558 ms
 8  if-12-6.tcore1.CT8-Chicago.as6453.net (216.6.99.46)  23.500 ms 206.82.141.134 (206.82.141.134)  60.538 ms 64.86.78.30 (64.86.78.30)  40.280 ms
 9  206.82.141.134 (206.82.141.134)  59.675 ms *  47.879 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
peterh
  • 4,953
  • 13
  • 30
  • 44
Sameer Puri
  • 121
  • 1
  • 4
  • You've been on SO for almost two years; can you adjust this question before someone flags it? Hint, if you reformulate, we probably don't need to actually see the traceroutes (really hard to read, and the answer is probably going to be that's how routes work anyway), but the traffic shaping part might produce a unique answer. – ǝɲǝɲbρɯͽ Mar 22 '15 at 04:02

2 Answers2

2

It isn't showing 30 hops. It is just timing out after 9, this is usual on residential connections because either your ISP or your router is preventing ICMP pings. My guess is that your router would be either hop 10 or 11 on that otherwise.

The outgoing connection determines the route. So when you are sending data to the server, your ISP is determining the route it takes based on various metrics. When you are receiving data from the server, the server's network chooses the route it takes based on various metrics. These metrics vary from host to host.

You won't be able to determine speed from a traceroute, only latency and possibly packet loss. I say possibly packet loss because ICMP packets (ping) aren't the best for measuring packet loss since routers treat them with low priority.

There is no way to tell traffic shaping from a traceroute and the route you take has nothing to do with traffic shaping. Just note that 220KB/s does not equal 220kbps. 220KB/s (Bytes, not Bits) is 1.76mbps. Still not the 30mbps you are expecting but there could be a variety of reasons for this, all of which are going to be hard for you to figure out from your end without a lot of testing.

Devon
  • 800
  • 1
  • 9
  • 20
0

The Internet is designed to be robust and route you around problem areas. Finding you another suitable path should take so little time (milliseconds or lower) that you don't realize you've avoided congestion.

It's only when none of the route choices are particularly good you start to see problems, and I'm spending some time in this answer so that it's more clear what you're proving. By your indicated hops...

Outgoing from you

  • hops 6-8 : Your trace took 3 paths, on hop 6 balancing between addresses ending in 204, then 72, then 129. Seems normal.
  • At hops 3 and 9 you can see that three results is not strange; each hop is tried 3 times.
    • " * " means "no response". Undesirable if random, 3 in a row is often normal when you can see past them and what you see isn't also sprinkled with "*".
  • Your round trip time (how many ms it takes for a request to return to you) is affected by shared hosting, time of day, Verizon and non-Verizon network investments, etc.

Incoming from the server:

  • 3,4: probably configured not to answer traces. This can be policy or opinion, or it may just be faster to drop the request. Traceroutes are diagnostic tools; unless you're the admin doing the diagnostics, it's just not as important to identify your hop as it is to pass everything that's supposed to go through you (like web requests, or requests for hops past you).
  • At hop 9 all you know is that the server can't see past it. That could be a firewall at any point on the path (no hops > 9 allowed), failure on the path the trace takes, or maybe you're not seeing a diagnostic response. Just remember: simply because you are receiving feedback to your trace on one connection doesn't mean the path the trace itself takes to reach you is the same one (though it's probably similar).
  • Hop 2 might be congested (>300ms, <1ms, >300ms) but it's probably just prioritizing "answering you" lower than its primary duties: passing traffic. If it were too busy, I'd expect every test past it to have times randomly over 300ms. None do.
  • All you know from hop 10+ is that the route isn't traceable. That's it. You might have even triggered a firewall rule that decided it was time to block you.

You do seem to have a random problem with (Devon provides better information in answer and comment) dropped packets hops 5 through 9, but one trace is hardly enough data, nor is it the only type of trace. The only thing you can really say is that in this trace, there may be problems typical priority adjustments after hop 3.

The primary problem is that you don't seem to be receiving the bandwidth you paid for. Though Verizon can run their own traces and coordinate with administrators in a way you can't, your problem may be closer to the server. Just call/write both places and ask. If necessary, output from my traceroute is better, but please remember that you're running diagnostics on symptoms, while they can run diagnostics on cause.

Community
  • 1
ǝɲǝɲbρɯͽ
  • 536
  • 3
  • 11
  • 2
    You can't determine if there is a problem on hops 5-9 because of packet prioritization on routers. Routers treat ICMP packets as low priority so dropped packets and ping spikes are common and normal. The only way to accurately determine if there is actually packet loss through a traceroute is to see if there is packet loss on the end host (computer) which is impossible on this route because the computer is not reachable with ICMP packets. – Devon Mar 23 '15 at 17:17
  • 1
    Okay; this comes from experience (and returning to an empty question) rather than something like ISP/Cisco training. Willing to correct other stuff or reduce, I'll just strike the error so people see your comment. Your answer is simpler anyway / thanks! – ǝɲǝɲbρɯͽ Mar 23 '15 at 17:35