Several years ago, NetFlow was arguably one of the most underutilized management assets relevant to network performance and security. It was generally available as a part of Cisco IOS software, but was rarely activated. At that time, it was cumbersome to access, view and interpret, and it often ate network performance.

This was a shame, because NetFlow offers significant value for performance management, capacity planning, and security across the networked application infrastructure. Much like RMON-based probes, NetFlow offers granular information on where, how and by whom specific applications are being used and how that usage affects the network. As such it can identify inappropriate behavior - too much Kazaa bringing down response time for an ERP application, for example - catch and diagnose denial-of-service attacks, help to troubleshoot bottlenecks, monitor the efficacy of QoS parameters, and support usage-based accounting and billing. NetFlow reveals information like source IP address, destination IP address, source port, destination port, Layer 3 protocol type and class of service.

NetFlow is now becoming more broadly used. Cisco has made some smart investments in improving NetFlow performance and accessibility. Cisco is even working on a Management Information Base for simple, summary access to NetFlow information, and the company is currently talking with the IETF about standardizing NetFlow. And perhaps most of all, Cisco has recognized the value of industry partnerships in tapping NetFlow for a much broader audience.

One of the most successful of these partnerships is with NetQoS, which offers SuperAgent for troubleshooting and diagnosing application performance, and ReporterAnalyzer for capacity-related troubleshooting and assessing the volume and impact of traffic flows. It’s ReporterAnalyzer that supports NetFlow and brings unique features to the process:

* ReporterAnalyzer can calculate outbound traffic for NetFlow. This is valuable because NetFlow only provides statistics for inbound traffic flows and so typically needs to be turned on at both ends of a link. While this calculation doesn’t include multicast traffic, broadcast traffic, bottleneck traffic, or router overhead measurements, it’s sufficiently detailed for many enterprise IT shops.

Denise Dubie is senior editor with Network World.