Author Profile - Chris Greer is a Senior Network Analyst for Network Protocol Specialists, a Seattle based Network Consulting company. Chris has 10 years of experience in analyzing and troubleshooting networks. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. When he isn’t hunting down problems at the packet level, he can be found teaching various analysis workshops at Interop and other industry trade shows. Chris also delivers Fluke Networks public courses and protocol analysis themed webcasts. He can be contacted at chris (at) nps-llc (dot) com.
When analyzing a problem on the network with a trace file, the solution may come down to data revealed in a single packet. For this reason, it is important that we understand the capture limitations of our analyzer, as well as the platform it is running on.
As is common knowledge, just because a laptop has a 1Gbps NIC does not mean that a software protocol analyzer will be able to capture traffic at Gigabit speeds without packet loss. In this test, our purpose was to find out the exact point where our software analyzer started to drop packets, so a hardware analyzer could be used when capturing at specific traffic levels. When capturing in a data center or on other key links, we can then watch for these utilization levels, and know when we will need to break out a hardware analyzer or special NIC (such as the CACE 1Gbps TurboCap card) and when a laptop with a standard NIC running a software protocol analyzer will do just fine. The purpose of this article is not to knock a software analyzer, but to understand the impact of some basic configuration settings in the analyzer as well as what point we need to step up the hardware platform we are running it on.
Tools Tested:
Wireshark installed on a Dell D610 Laptop (1Gbps NIC, 1.6GHz Processor, 500MB RAM)
We also shot traffic at a dedicated vendor software analyzer on the same laptop as a basis for comparison.
Tests Run:
- 100,000 packets at Gigabit line rate for 64, 512, and 1518 bytes respectively. Each analyzer captured as much as possible at default settings.
- Using the kernel buffer, we tuned the analyzers for maximum capture. Traffic was then transmitted at gradually increasing rates to determine the exact point where it started dropping packets.
Test Setup:
The test was run using a traffic generator capable of filling a gigabit pipe generating traffic to another machine on the network. A Gig tap was used in-line between the traffic generator and the Gigabit Ethernet switch. The analyzer under test was connected to the tap and tested for capture capability.
Results:
The first test was run by transmitting 100,000 packets at line rate. Using the tap, each analyzer captured as much as possible of the stream. The packet counts are in the chart below.
Most people use Wireshark in its default configuration. But notice that by changing the kernel buffer to 100MB, we were able to dramatically improve the capture capability! This buffer can be changed in the interface capture options:
Understand however that adjusting this buffer will affect how much load the analyzer places on the laptop resources. So the larger you set this buffer, the slower the machine may run. Don’t adjust this buffer unless you need to!
These capture numbers are even better when using the non-GUI interface capture features of Wireshark such as tshark.
Note that although the dedicated software analyzer did slightly better at the outset, it still depended on the underlying laptop in order to capture. So it could not capture everything on the wire.
Max Bandwidth Test
The second test was a maximum bandwidth shootout. At what data rate did the analyzers start to drop packets?
Again, using tshark we were able to maximize the capture capability of wireshark and significantly improve the rate at which it is able to capture.
Conclusion
So there we have it. In its default state, the software analyzer on a standard laptop starts dropping packets as the traffic load approaches 30Mbps. If we see these traffic levels on the network and we need to capture. The first step is to adjust the kernel buffer. When we do this, we can comfortably capture up to 100Mbps streams with no packet loss.
As a rule of thumb, if the traffic rate at or below 100Mbps, the software analyzer with a few tweaks will work just fine. But if the data rate exceeds 100Mbps, it’s time to break out the hardware.
At NPS, we use analyzers from all over the board, expecially Wireshark, regularly. In data centers or other environments at high data rates, we make sure to use special capture cards or hardware analyzers to do the capturing so we don’t miss a single packet. When capturing on the network, no matter what the traffic level, it is important to know thy hardware!
Continue reading other LoveMyTool posts by Chris Greer »
Recent Comments