- Justin Baker
- October 16, 2009
NetFlow is a network protocol for collecting IP traffic information, developed by Cisco Systems. It was a major advancement in the measurement and monitoring of network traffic when it first debuted in 1997. NetFlow captures useful data such as the timestamps for the flow start and finish time, number of bytes and packets observed in the flow, L3 headers that capture source and destination IP addresses etc. Data captured via NetFlow can be used to visualize traffic patterns associated with individual routers and switches as well as for the entire network. Over time, NetFlow has become a fairly standard part of the network engineers' arsenal, who utilize both open source and commercial NetFlow tools to help them tame the network beast.
12 years have passed since the first introduction of NetFlow. During this time, there have been lots of changes. The network as well as surrounding technologies have all gotten a lot more complex. Relying on NetFlow alone is now woefully inadequate for solving the more complex performance issues.
At an early pitch meeting for ExtraHop, one of our potential investors summed up our technology by saying "I get it, it's a better NetFlow than NetFlow." This statement doesn't completely capture the value of ExtraHop, but I thought that it's an interesting comparison. Given the popularity of NetFlow, it would be worthwhile to contrast the ExtraHop approach to NetFlow-based tools and talked about why he may be right. What makes the ExtraHop system a better NetFlow than NetFlow? Here's my top 5 reasons.
NetFlow is like a phone bill. With NetFlow, you can certainly see that x conversations have taken place, who called who, and how long was the call. But there is no notion of what's discussed in the conversation. That means NetFlow is fine for systematic failures, but doesn't provide much help for intermittent problems where you need to see what's the difference from transaction to transaction, why are some succeeding while others are failing. In contrast, ExtraHop provides very granular detail about each and every transaction/conversation, so you can drill down and discern the root cause.
NetFlow stops at L4. ExtraHop goes to L7. The difference is application level data that can shed a lot more light into cross-tier issues.
NetFlow more often than not represents sampled data. Even under the best scenario, the number of supported flows/sec will be limited by the available processing power and memory. This means NetFlow will most likely be painting an incomplete picture of what's happening on your network. Where as ExtraHop does what we call "full stream reassembly", every single packet and every single transaction is examined in detail. Even though we throw away the raw packets, all important performance information is captured in its entirety.
NetFlow has to be enabled all routers. First of all, this can become quite tedious and adds to the network engineering team's workload, especially in upgrade scenarios. More importantly, what if there was a problem and you discover that segment of the network does not have NetFlow enabled? Then it's just a black hole. The ExtraHop system is completely passive, doesn't require any special configuration and is always on. That's a comfortable feeling, I think.
Let's compare the use cases. NetFlow can help you detect system wide anomalies, L3 events like ICMP storm, DOS attack etc. But it's not very helpful when you have database, HTTP, DNS and storage issues. ExtraHop helps to shed light in each of those cases and more, providing comprehensive L2-L7 visibility that's invaluable for both network and application teams.
This is a companion discussion topic for the original entry at http://www.extrahop.com/post/blog/extrahop-analysis/better-netflow/