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

I realise this is very subjective and dependent on a number of variables, but I'm wondering what steps most folks go through when they need to diagnose packet loss on a given system?

share|improve this question
    
What's the "system" ? Do you mean that you have a single server (or desktop) experiencing packet loss? Or is it a whole network segment? How have you diagnosed this as packet loss (which I'm assuming you mean is network-caused) and not, for example, poor performance on an application server, running out of transient ports or Java heap or a million other possibilities? –  mfinni Nov 30 '10 at 13:41
    
I realise it's a bad problem description. Think of it as being purely academic and hypothetical. Assume it's packet loss, just curious to know what steps most engineers take. –  KushalP Nov 30 '10 at 14:25
add comment

3 Answers 3

up vote 11 down vote accepted

I am a network engineer, so I'll describe this from my perspective.

For me, diagnosing packet loss usually starts with "it's not working very well". From there, I usually try to find kit as close to both ends of the communication (typically, a workstation in an office and a server somewhere) and ping as close to the other end as possible (ideally the "remote end-point", but sometimes there are firewalls I can't send pings through, so will have to settle for a LAN interface on a router) and see if I can see any loss.

If I can see loss, it's usually a case of "not enough bandwidth" or "link with issues" somewhere in-between, so find the route through the network and start from the middle, that usually gives you one end or the other.

If I cannot see loss, the next two steps tend to be "send more pings" or "send larger pings". If that doesn't sort give an indication of what the problem is, it's time to start looking at QoS policies and interface statistics through the whole path between the end-points.

If that doesn't find anything, it's time to start question your assumptions, are you actually suffering from packet loss. The only sure way of finding that is to do simultaneous captures on both ends, either by using WireShark (or equivalent) on the hosts or by hooking up sniffer machines (probably using WireShark or similar) via network taps. Then comes the fun of comparing the two packet captures...

Sometimes, what is attributed as "packet loss" is simply something on the server side being noticeably slower (like, say, moving the database from "on the same LAN" to "20 ms away" and using queries that requires an awful lot of back-and-forth between the front-end and the database).

share|improve this answer
    
+1. Beeing a customer support network engineer, I usually follow this path too. –  petrus Apr 2 '12 at 20:47
add comment

I will start by using packet capturing tool such as: wireshark (on Windows) and tcpdump (on Linux terminal).

I will also check the firewall configuration (host firewall as well as network firewall).

share|improve this answer
add comment

Isolate, then eliminate.

Find the smallest subset of paths with the problem. Do this by testing out different combinations and/or distilling user reports. Don't forget to factor time in the equasion. Maybe it's only packetloss on all traffic to a specific network, or maybe only the wireless clients are suffering. Take different traffic types into account (rate limit on pings). Find the most reliable and easily repeatable way to test it.

Then eliminate potential causes. Reduce traffic on the links (temporarily), remove interference sources from the spectrum, disconnect certain clients. Eventually you'll find the source of the problem.

You can sometimes take shortcuts by looking at packet dumps or take guesses (it's always bittorrent). Also, tell your professor serverfault is awesome.

share|improve this answer
    
It's "Exterminate" and not "Eliminate". –  Andrew Smith Jun 17 at 20:20
add comment

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.