Enterprise Management Associates has been talking with NetFlow adopters and is coming out with a short report as part of a larger research report on application flow management. There are clear indications that NetFlow adoption is on the rise. Why? I have some answers, but I’m holding finalization of the report for your input.
What are your experiences - good, bad and in between - regarding NetFlow?
For those of you who don’t know, NetFlow, much like RMON-based probes, can give you information on where, why, how and by whom specific applications are being used and how the usage might affect the network. NetFlow is a part of Cisco’s IOS software, and the current version, 9, is currently moving toward standardization in the IETF as IPFIX. Networking vendors other than Cisco, such as Enterasys and Juniper, are taking a role in shaping the standard, and are already showing interest in adopting IPFIX. This, of course, makes NetFlow/IPFIX far more attractive as a consistent source for information about application flows over a network in heterogeneous environments.
NetFlow provides the following information:
* IP address source (who is sending an application service?)
* IP address destination (who is receiving service?)
* Source port (what application is it?)
* Destination port (what application is it?)
* Layer 3 protocol type
* Class of service
NetFlow is instrumented to capture inbound traffic only, so typically instrumentation at both ends of a link is required.
Service providers have been inclined to use NetFlow for years. They have been attracted by its scalability in large WAN environments; its abilities to help support optimal traffic flows across peering points; its use in assessing infrastructure optimization on a per-service basis; its value in troubleshooting service and security issues; and its foundational capabilities for chargeback and service accounting.
However, NetFlow is far from a panacea. It does nothing to provide application response time, and its ability to identify applications based on port signature is far from adequate given the growing trend toward dynamic port allocation. Moreover, in the past, NetFlow was difficult to implement and a hog on performance. It was, therefore, virtually best practice not to turn it on in most IT shops.
So why are IT shops adopting NetFlow more aggressively, or at least more actively considering it?
Well, a lot has changed. EMA has seen router performance impact minimized to around 2% to 3%, and NetFlow deployments roll out in as little as a week. Another reason for adoption is enhanced management software packages for reporting and analyzing NetFlow - such as those from Crannog, Micromuse, NetScout and NetQoS. NetQoS can estimate outbound traffic flows based on inbound flows to simplify deployments, and NetScout recently introduced a NetFlow collector appliance for tapping multiple NetFlow sources at once. NetFlow is also valuable to service modeling and accounting applications such as those from Evident, and to security vendors such as Q1Labs and Arbor’s Peakflow, where NetFlow’s ability to capture anomalous volumes of traffic becomes valuable for alerting on worms, denial-of-service attacks and other security-related issues. Also, third-party products have improved NetFlow’s ability to identify unique application flows, through approaches ranging from application server mapping to packet analysis technologies designed to scale with broad WAN deployments.
It should be pointed out that NetFlow/IPFIX is just one of many technologies designed to capture and analyze application traffic flows. Many of its benefits can be approximated, and at times even surpassed by other approaches, most notably a variety of packet analytics. However, what NetFlow/IPFIX has that’s distinctive remains the inherent advantages of leveraging current infrastructure for capturing pervasive, link-specific traffic behaviors over large, often geographically dispersed networks.
What are your thoughts regarding NetFlow? I’d love to hear from you. Send your comments to me at mailto:email@example.com