If you’ve ever been to the doctor and had an EKG test done, you know that they get super-excited about every little spike on the EKG trace. The cardiologist stands there and “oohs” and “ahhs” over the slightest deviation from what they know to be normal. To me, it just looks like a squiggly line.
In the network performance world, packet traces provide the EKG equivalent to examine network health. Anyone that’s worked with me over the last 20 years knows that the first thing I want to see when someone says they have a network performance problem is a packet trace. The really good news is that most network engineers (and even some system administrators) are able and willing to use a tool like wireshark (formerly ethereal) or tcpdump to capture a trace. Sadly, my experience is that once they have the trace, most folks don’t know how to “read” it — it’s the same squiggly line problem, just in the network space.
At some level, extracting useful data from a packet trace is something that comes with experience, and perhaps is a bit of an art. There are (literally) hundreds of interesting conditions that a packet trace can indicate, prove, or disprove. But, success with packet trace analysis usually boils down to 3 things: