NetFlow and other flow-based technologies, like sFlow, Jflow, and IPFIX, have become increasingly popular given their leverage of existing resources –network switches and/or routers — to obtain data that is already being processed by these devices. However, as the old adage goes, “There is no free lunch.” Flow-based solutions lack the ability to solve specific problems experienced by the end-user, and can not only stress your network with additional data, but lose key data when your network is most heavily utilized.
End-User Frustration: Why packets and payloads are so important
Problem: You receive a call from an end-user who is experiencing significant application performance problems. Of course the immediate blame goes to the network. How do you quickly fix this problem in a flow-based solution?
Answer: Without access to the packets and payloads, the network engineer would have to perform a great deal of experimentation with the user. Additionally, without help from the application engineer, the network engineer would be hard pressed to figure out the issue if it’s not a simple network issue. Now you have three players that are experiencing frustration: end-user, network engineer, and application engineer.
Remedy: Get a solution that is able to troubleshoot and provide you with access to both the payload and packet information.
In this video Jay Botelho, Director of Product Management of WildPackets, walks through the process of determining the issues centred around a particular user and a particular application, as discussed in the above scenario, and displays how simple and short this process can be when using a solution that provides visibility into your packets and payloads.
Too Much Traffic on Your Network? Flow-based technologies generate traffic of their own
Flow-based analysis generates additional network traffic, with the volume of traffic proportional to the size of the network segment being monitored. The typical packet size is around 1500 bytes, which is relatively large. These packets come in spurts ranging from tens of Kilobytes to several Megabytes of traffic for each reporting interval, depending on how many flows are monitored by the switch or the router for that given interval. NetFlow packets usually contain data for 5 to 10 flows per packet.
On highly utilized network segments, this added traffic could cause undesirable results.
Flow-based technologies break down under pressure: How flows react to a heavily utilized network
All flow-based solutions share hardware resources with the prime directive of your router or switch – forwarding packets. If your router or switch is heavily utilized, it will focus first on its prime directive, compromising flow-based reporting. This can create intermittent inaccuracies in your monitoring and reporting that are very difficult to detect, affecting your ability to collect essential information from your network at a time when it is needed most.
In addition, the flow records sent from the switch or the router to the flow-based processor are based on UDP packets, an unreliable transport mechanism. There are no acknowledgments with UDP, so dropped packets result in missing and inaccurate flow-based data. Remember, each NetFlow packet reports on 5 to 10 flows, so for each dropped packet many flows are ignored. And this is most likely to happen when the network is busiest, compounding your inability to get an accurate picture of the current state of the network.
Sampling is another important factor to consider when evaluating flow-based analysis systems. The default configuration for NetFlow is to monitor and develop flow records for 100% of the packets – no sampling. But it can be configured to “1 out of k” static sampling, or the network device itself can switch to a sampling mode when network traffic gets heavy. Sampling leads to inaccuracies in reporting, and these inaccuracies can vary substantially since it all depends which flows are being ignored through the sampling.