Network packet capture has been a tool of the trade for 2 to 3 decades for most network engineering teams. “Packets don't lie” is a core belief for network engineers. Going to work each day without access to packet captures would be like a doctor doing her rounds without a stethoscope. Given that packet capture is such a core capability and has had multiple decades to mature, you’d expect any products in this space to be easy-to-use, reliable and cost effective. However, packet capture, although a simple concept is still proving difficult to execute. Here's 5 reasons that why that is still the case:
Data centre networks have seen a 40x increase in speeds as they have moved from 1Gbps to 10 Gbps and now to 40Gbps over the past 5 years. Disk systems that can guarantee sustained capture at 40Gbps are not cost effective, and even if they were, 40Gbps can fill 16TB of disk space in 1 hour! Leveraging the ever increasing core counts and assigning threads for compression of this data before capture is one intelligent solution to this problem - if properly implemented. Network data can be highly compressible. I've observed compression factors of 3x to 10x, which means capturing sustained 40Gbps from the network can be made cost effective and achievable.
When someone claims their solution captures at 30Gbps, what does this mean? All network engineers know there is never a single performance number. A number like 30Gbps can represent as little as 2 million packets per second or as much as 45 million packets per second, depending on packet size. For a network capture solution to provide value, it needs at a minimum support for queries by values contained in the packet headers. This requires some level of processing on every packet. All solutions need to provide much more than a headline number. Network engineers need guarantees that the packets will be captured, and typically the most crucial packets are the ones sent at peak utilization, exactly when the capture solution may be at its limits.
If a solution is designed to capture and write packets at 40Gbps, a crucial consideration is: How responsive are the packet queries and exports during busy capture periods? Disks clearly can not write and read simultaneously. When users need access to packet captures, they are typically on the hot seat and need the product to be responsive to all packet queries. During these periods, the capture system has to ensure a portion of the I/O resources is available to serve the user's request while still ensuring no packets are dropped. A poorly designed capture system can easily become unresponsive to all users during critical, business-impacting events.
This is crucial for large organizations. Many workflows across multiple teams and NOC's can depend on fast and intuitive access to packet capture. If users need to be trained on how to access packet captures, this can involve potentially 100's of personnel across the organization. Any packet capture solution at a minimum needs to support the most common packet queries used by the leading tool in this space (ie: tshark) and shouldn't deviate from well known syntax like "ip.addr == ". Ideally, this should be accessed from a web browser and require no specialized client side tools or knowledge of the packet capture platform.
As I said, the packets don't lie and they have proven their worth multiple times over to many organizations. Systems can now examine the packets and their payload to report on both network and application performance. Your chosen packet capture solution should be a platform that can optionally enable packet analytics for real-time proactive reporting and alerting on both network and application performance. The platform should enable you to realize and reap the benefits of both packet capture and real-time pro-active analysis of those packets.