Any business needs a strong and healthy network supporting its critical business operations. Delays in web pages loading or online applications will frustrate users and lose customers, even with delays as short as a fraction of a second. To maintaining the health of critical infrastructure and applications and spot problems before they affect customers, IT teams need visibility into how those networks are running. This means they need some kind of network monitoring solution.
There are many ways to monitor a network and each approach has pros and cons. They fall into two main camps. One uses protocols like SNMP and NetFlow to provide an overview of the network’s performance. The second examines the actual packets being sent back and forth on the network. Solutions using NetFlow are helpful for capacity planning, trend analysis and utilization, but they lack the important precision of packet-based analytics tools and don’t provide enough information to accurate troubleshoot application performance, latency issues, TCP/IP or VoIP problems. By using both methods together, enterprises can get complete visibility into their networks and maximize their existing infrastructure.
How Does Network Monitoring Work?
Let’s look at these two methods in more detail. NetFlow is a well-known, well-established standard that provides conversational information about network status. It offers greater precision that older protocols like SNMP and delivers data at intervals of around 1 second, depending on the equipment being monitored. NetFlow provides a good global view of a network and can be extremely helpful when monitoring the network’s general health. NetFlow data, which typically comes from Layer 3 devices like routers and firewalls, provides good information about traffic volume between devices. But if you need to use multiple ports, NetFlow is at a disadvantage. This is where packet-based analytics come into their own.
Packet-based monitoring, on the other hand, involves recording and copying samples of actual network traffic and analyzing it. It’s much more precise than NetFlow, with interval times as short as a few nanoseconds. On top of that, the data is completely based on the original payload, so it isn’t abbreviated or compiled. Since packet data is more granular, it’s much more helpful for troubleshooting specific problems.
The packet-based approach is also completely passive, so it doesn’t burden the network or interfere with existing operations or services. As you can imagine, this is very important, especially because adding more traffic to a network that’s short on bandwidth will make existing problems worse. Packet analysis also allows users to drill down and discover information about how the network is behaving, not just whether it’s operating well.
Limitations of NetFlow
NetFlow was first introduced by Cisco in the late 1990s, so there are limits to the information it can provide on modern networks. Flow-based technology is useful only up to Layer 3 (the network) and occasionally Layer 4 (transportation between hosts). Users can see where data traffic is being generated, but NetFlow struggles to identify any activity associated with content delivery networks and applications that use multiple TCP or UDP ports. It also has no visibility into the payload or contents of individual packets.
For example, if an IT team gets a call about a slow network or a CRM that’s unable to save any records, they need to start looking at the root cause. In this scenario, NetFlow would reveal that traffic is going between the client and the server, and that it’s running on a specific port. It could also show what volume of traffic is produced by each of the clients. In other words, an IT worker could verify simple problems like whether the server is up and running and whether the port in question is operational. But NetFlow data would not be able to help them find the cause of the problem in detail.
NetFlow and Packets are Better Together
Conversely, packet-based analysis has been designed specifically to reveal the ‘how’ of the network. Rather than being about just the volume of traffic, these solutions expose vital details about performance and application response. Users can compare network latency with application latency. They can see the efficiency of TCP communications on their network. They can evaluate the performance of VoIP and video over the network and determine if these real-time protocols are prioritized correctly. None of this can be achieved with NetFlow or its derivatives.
When your team uses packet-based analysis in tandem with NetFlow, they should be able to answer questions like, “Is this issue caused by the network or the application? Is it isolated to a single user, a single server, or the entire network. Are critical applications using network resources efficiently? Is my network properly configured for voice and video traffic and does this traffic affect other network transactions? Are protocol issues interfering with critical functions, like user authentication or our major business applications?”
NetFlow certainly has its place in the network monitoring hierarchy, but its limitations make it less than ideal in many situations. For most network professionals, having access to packet data significantly accelerates mean-time-to-resolution (MTTR). Fixing problems faster means more productive employees and more satisfied customers. Plus, your IT team can spend the extra time upgrading your infrastructure or pursuing digital performance initiatives rather than chasing trouble tickets constantly. For a healthier network, look into combining these two network monitoring methods!