Designing and maintaining a network that delivers uninterrupted performance is a crucial function of most NetOps teams. But with new technology challenges around cloud and software defined architectures, many struggle to optimize and troubleshoot the high-performance networks of today.
According to a recent survey from LiveAction, 20% of NetOps teams are focused on improving application performance across the network, 19% are focused on improving network monitoring, and 15% are focused on improving performance at remote sites. Doing this effectively requires visibility into flow and packet data. When aggregated and analyzed properly, NetOps teams can gain valuable insights and operate more predictable, high-performing networks.
NetOps teams traditionally rely on network performance monitoring solutions to collect this data, but what are the pros and cons of flow and packet data and how is it used to troubleshoot networks?
First, let's quickly define flow and packet data. The goal of network flow monitoring is to tally, log, and analyze all network traffic as it passes through routers and other network devices, essentially creating a summary model of network usage. Deep Packet Inspection (DPI) is a process commonly used to inspect the payload content of each packet to make determinations about whether to act on that packet by rejecting it or allowing it to pass through the network. DPI can also be used to passively collect the traffic traversing the network to add visibility and troubleshooting capabilities into network monitoring solutions.
Packet capture is also used to store a mirror copy of network packets for detailed network analysis, using forensic search and filtering. The stored mirror copy can later be examined for a particular time frame, when new performance, security, or forensic incidents arise. When network messages are packetized (broken into pieces), they are then routed over the internet to other connections to be reassembled at their destination. Each packet is generally organized into three segments regardless of size — the header, payload and footer. As packets flow through the network routers, their headers are read and "fingerprinted" based on five to seven packet header attributes.
Today, most routers have some brand of xFlow export feature that allows flow data to be sent from the router to a collector and analyzer. Netflow is the de facto industry flow protocol (originating from Cisco), but other popular protocols include IPFIX, J-Flow, and sFlow. Source and Destination addresses tell who the originator and receiver of the traffic are. Ports and Class of Service tell what applications are in use and their traffic priority. Device interfaces tell how devices are utilizing traffic. By tallying packets, the total traffic flow amount can be determined. Timestamps are useful for placing flows in time and determining their rates. And finally, Application and Network Latency provide measurements about how long each transaction takes.
What are the pros of flow and packet data?
First, flow data is simple to set up. Most routers and switches come standard with the xFlow protocol feature. This means you get vendor-agnostic visibility across just about every network segment. Capturing flow data also requires no extra cabling or equipment, and in most cases no extra licensing, providing excellent network visibility essentially "for free." It also has low network bandwidth overhead since flow data approximates only 0.5% of network traffic, and no clients are necessary on end systems.
For Packet data, it's valuable because it contains every bit of information for every transaction on the network. It allows NetOps to understand bandwidth usage by analyzing details of application and user behavior.
Excessive bandwidth utilization often occurs over very small time periods, typically referred to as "microbursts" since these event happen over microseconds to milliseconds. These events are hidden by the typical reporting rates of xFlow data, but are easily exposed by packet data.
Packet data is also ideal for detailed monitoring and troubleshooting on critical applications, servers and connections. This helps with answering critical questions, like whether the network or the application is the root cause of a problem. Packet data provide specific, interpacket timing, and can expose critical data in payloads that provide proof of application problems. Packet data also offer significant name discovery, such as application names, file names, website URLs, and hostnames, which can be used for both detailed troubleshooting and reporting on custom, web-based applications.
