Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Problem

I'm having high packet loss, according to mtr, when sending packets over the Internet. Should I complain to my ISP?

Story

I am reading the OReilly Linux Networking Cookbook and the chapter Using traceroute, tcptraceroute, and mtr to Pinpoint Network Problems drew my attention. Pinging a host like Google over the Internet from my ISP gives me record delays of 1200ms and higher (not only since today; since long time), so I thought I'd do no worse analyzing the way of the packets with mtr.

Mtr is a network diagnostic tool that combines ping and traceroute into one program.

The excerpt and, at the same time, the reason for this question thread is:

If any of these consistently get hung up at the same router, or if mtr consistently shows greater than 5 percent packet losses and long transit times on the same router, then it’s safe to say that particular router has a problem. If it’s a router that you con- trol, then for gosh sakes fix it. If it isn’t, use dig or whois to find out who it belongs to, and nicely report the trouble to them.

Issue

See the mtr --report www.google.com output yourself: (In total 12 tests, 1 test every 5 minutes; this is the report which represents the reliable 'average')

HOST: km                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.0.1                   0.0%    10    1.2   3.7   1.2   6.3   1.8
  2. 10.150.144.145               10.0%    10   89.1  77.3  58.7  90.4  11.1
  3. 172.16.251.1                 50.0%    10   52.2  62.1  52.2  70.3   8.8
  4. 172.16.250.54                60.0%    10   74.9  87.5  74.9 100.4  12.1
  5. 172.16.250.251               40.0%    10   68.6  75.4  52.4 113.8  24.2
  6. 200.85.47.2                  10.0%    10  109.6 110.6  80.6 146.2  21.1
  7. 201.217.4.113                 0.0%    10  103.6  87.3  64.4 103.7  12.2
  8. 201.217.0.9                   0.0%    10  229.0 102.6  46.7 229.0  48.1
  9. 201.217.0.3                   0.0%    10   78.8  88.1  53.9 128.8  23.8
 10. So2-3-2-0-grtbueba2.red.tele  0.0%    10  134.1 129.2  71.3 176.6  29.2
 11. Xe4-1-3-0-grtmiabr7.red.tele  0.0%    10  257.3 255.1 221.0 291.6  21.1
 12. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  290.4 267.0 213.2 319.1  31.0
 13. Xe2-0-2-0-grtmiana3.red.tele  0.0%    10  300.0 250.8 217.3 312.7  34.6
 14. GOOGLE-xe-5-0-0-0-grtmiana3. 10.0%    10  249.8 256.9 206.7 324.0  34.6
 15. 209.85.254.252                0.0%    10  254.3 253.8 217.1 283.1  23.4
 16. 209.85.254.252               10.0%    10  301.2 280.6 252.1 319.7  21.6
 17. 72.14.236.200                10.0%    10  273.4 278.4 238.4 311.0  25.0
 18. 216.239.49.145               20.0%    10  291.0 276.3 240.4 293.5  19.1
 19. 72.14.232.25                 10.0%    10  297.9 286.3 242.4 337.1  30.0
 20. yo-in-f105.1e100.net         70.0%    10  300.7 304.7 280.3 333.0  26.6

You see immediately that hosts 3-5 are experiencing a very high packet loss far over 5%. Doing a whois database query shows me that those are name-servers (please correct me if I'm wrong).

Questions

  1. What should I tell to my ISP? How to describe the problem..?
  2. What kind of research can I do in addition to facilitate troubleshooting? *1
  3. Any suggestions?

*1 Those guys from technical supports aren't always understanding or I can't express my problem clearly enough (Sometimes they're just idiots without doubt)

share|improve this question

4 Answers 4

up vote 8 down vote accepted

Many routers are typically programmed to give lower priority to ICMP packets so they aren't "wasting" processing power over "real" traffic. Just because you see a hop with high loss doesn't mean it's slowing down "real" traffic; it may only be throwing away ICMP. That's not necessarily good because it might mean the router is too busy, but it's not guaranteed.

The router may also be programmed to limit the number of responses it sends to ICMP packets in an effort to mitigate DoS attacks.

share|improve this answer

It can be that the error is inside your network.

Which one is your internet router/gateway ?

Chances are that

3. 172.16.251.1    50.0%    10   52.2  62.1  52.2  70.3   8.8
4. 172.16.250.54   60.0%    10   74.9  87.5  74.9 100.4  12.1
5. 172.16.250.251  40.0%    10   68.6  75.4  52.4 113.8  24.2

are inside your own network.

share|improve this answer
1  
Why don't you think this is some dude doing it at home and 192.168.0.1 is his gateway? –  mrduclaw Dec 25 '09 at 13:52
    
Well it can be. But he did not get a public ip? Then it is all bad already. –  cstamas Dec 25 '09 at 20:41
1  
@cstmas: because when you're inside the network you can only see your (isp's) router's local side. Otherwise you'd end up seeing two ip addresses for every router (its front side and its back side). Try a standard tracert www.google.com from home and have a look. –  BuildTheRobots Jan 4 '10 at 20:57

What kind of connection and subscribed bandwidth? DSL, leased line, frame relay, cable? 768 down/128 up... etc.

You can get more realistic information by using WireShark, and capture/filter packets between two hosts for a period of time (30 minutes). Then use the Statistics > TCP Stream Graph > Round Trip Time Graph. Round Trip Time (RTT) is the actual delay at the tcp layer.

share|improve this answer

Given that you have a zero loss at hop 15, you know that you can get traffic all the way there without losses. All loss numbers on hops 1-15 are "local", i.e. the routers haven't responded to ICMP but they have forwarded your traffic.

The most loss it at the last hop, number 20, so the best guess is that the problem is congestion at the other end. A problem report to your ISP will do no good, but perhaps a complaint to whatever service it is on the other end might help.

Edit: I know this is an old question, but I think it deserves clarification about how to interpret loss numbers >0 followed by loss-free hops.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.