Free Wireshark training – and the 10 truths of network analysis

Last week, I was working my way through my RSS backlog when I spotted Thomas Lee’s post highlighting some free Wireshark (formerly Ethereal) webcasts by Network Protocol Specialists.

Wireshark is an open source packet capture and analysis tool (a bit like Microsoft Network Monitor – but available for a variety of platforms as well as in portable application and U3 form). I’ve struggled with deep packet-level networking since my days at Uni’ but a little knowledge in this area can really help when troubleshooting connectivity, so I registered for the first session and found it both worthwhile and interesting as Mike Pennacchi explained:

  • Analyzer placement.
  • Starting up Wireshark.
  • Selecting an interface.
  • Basic capture filters.
  • Capturing packets.
  • Displaying and decoding packets.
  • Saving the trace.

The next two sessions will look at:

  • Using display filters effectively.
  • Long term captures.

and:

  • Separating the good traffic from the bad traffic.

If you want to know more, check out the video from session 1 – or register for the next two sessions on the Network Protocol Specialists website.

In the meantime, I’ll round up this post with Mike’s 10 truths of network analysis:

  1. The wire does not lie. It is not out to prove a point, nor is it politically motivated. Interpreting traffic on the wire can help to solve problems.
  2. Packets cannot hang around at a device for more than a few milliseconds. Routers and switches do not have large enough buffers for packets to “hang around” – they may get dropped and retransmitted – or an application may be holding on to them. Network analysis can help to identify where the delay is.
  3. The total response time is the sum of the various deltas. Long response times may be the result of many packets with small gaps or fewer packets with long gaps.
  4. Every application program can be diagnosed. Solving them is a different issue.
  5. Focus on eliminating components that are not part of the problem. Figure out which layer of the OSI model is causing the problem, then implicate or exonerate.
  6. Don’t guess. Only state the facts after thorough analysis.
  7. Don’t believe anything that anyone tells you. Carry out your own troubleshooting and analysis. Be thorough.
  8. Explain the problem and diagnosis in a way that can be understood by all. Avoid misinterpretation and misunderstanding.
  9. Understand how to use the analysis tools before problems occur. And practice!
  10. Look for differences between working and non-working examples. If the normal situation is captured then it’s like a digital photo for comparison.

And finally, if this sort of thing is what interests you, Network Protocol Specialists have created a LinkedIn group for protocol analysis and troubleshooting to provide tips, tricks and valuable information to network professionals, application developers and anyone tasked solving computer network problems.

Leave a Reply