Have you ever had a nightmare where you are being chased and you can’t just seem to run away fast enough? No? Well, maybe you’ve tried running through snow up to your knees or swimming while wearing jeans. All of those examples point to situations that feel like something isn’t quite right. Cases where there could be better performance if only something was changed or improved. Sometimes this same thing happens to network devices.
Several hundred users lost network connectivity. They went down randomly, one by one, and over a short period of time. Some users had intermittent connectivity. All of the network devices were online and functional. Users were roaming the halls and getting bored. This called for a packet capture, but with clients offline it had to be done on a network switch. In this instance, the capture was performed at the distribution switch on the layer 3 VLAN.
I recently sat for the Wireshark Certified Network Analyst certification again. This will be the second time I have taken it and the second time I have passed. I have taken several various networking certification exams, networked with people who have sat for others, and read about many more. Keeping all of that in mind, I think this is one of the most straightforward certification tests I have seen. Laura Chappell, Gerald Combs, and the team have done a great job with the books and preparation materials.
Using file sets in Wireshark is a great feature. It allows for quickly navigating between smaller files instead of experiencing sluggish performance when analyzing one large file. However, there are times when packet captures were taken using a system other than Wireshark (such as TCPDump or Dumpcap). Other times someone else performs the captures and uses a different naming convention. Either way, there are times when it would be nice to convert these names into Wireshark’s file set naming convention.
While the general rule of thumb is to capture at the client, or at least start there, sometimes it’s necessary to take captures at both ends of a connection. The client perspective will allow you to view the problem as it is seen from the client. The server perspective might show the same thing. Or, in some cases like this one, it will provide the reason for the problem. The problem was that a webpage wouldn’t load.
In order to understand application performance across the network, we first have to understand the basic mechanisms. In this case that foundation is built on TCP, and, more specifically, the built-in TCP Performance Options. There are many things that can be done in an application to improve performance. There are also several options from a network perspective, and more still in the operating systems. However, these all rely on the underlying protocol.
Start the Capture Now that you’ve decided where to capture, and you’ve prepared your interfaces and filters, you are ready to perform the capture. All you have to do at this point is hit the start button or double-click the interface in the list. There are usually multiple interfaces listed, so make sure you know which one you are wanting to use. Generally, this may be indicated by a small moving graph to the right of the device name indicating there is traffic present (the screen shot below currently show no traffic as I was in a lull).
Packet captures give us a very detailed and in-depth look at network traffic. They can be used to establish baselines, discover network devices, diagnose application and performance issues, or identify security threats. The previous post described what packets are and their function at a high level. It also gave an overview of the process used to capture them. Once you have identified your purpose for performing a capture, you can begin preparing for it.
How do you go about catching the one of the fastest things known to man (light) at a specific point in time with pinpoint accuracy over and over again? With a little patience and your network card, of course! This post is an introduction to the process of capturing network traffic (aka “sniffing” or “tracing”). With most of my blog being dedicated to network performance analysis, a post like this is foundational, and will help you understand the basics moving forward if you are new to “sniffing the wire”.
*Disclaimer: all captures in this post were anonymized using TraceWrangler. I was recently asked to help with a performance issue. I was informed a transfer was going to take weeks instead of a couple days as expected. The transfer rate was getting 80Mbps throughput max on a 10Gbps connection. So, I setup captures at both ends and got to work. This is just a quick summary of that work with the classic tell-tale signs of a performance problem.