You don't know NetFlow - Mike Patterson

Mike Patterson speaks out
Learn more about Mike Patterson...
Archive

Aironet

Competitive Lab Tests

Tech Forums

How-to Tutorials

CCIE Gossip

The Problem with NetFlow

Hopefully you are asking yourself "So what's new?" or "What's wrong with NetFlow and IPFIX?" These are great questions which I will try to answer. The problem with NetFlow is that it is proprietary to Cisco which means that although it can be copied by other vendors, exporting unique metrics by carving out element identifiers runs the risk of being trumped by Cisco. In other words, NetFlow is not completely friendly to other vendors. Cisco did however offer ranges of elements to vendors who requested them (Riverbed, Enterasys, etc). How nice of Cisco was that?

The Problem with sFlow

The problem with sFlow is that it is proprietary to InMon. Although some refer to sFlow as a standard, to the best of my knowledge none exist. And by the way: an RFC is not a standard. The other problem is that sFlow is not a flow technology. It's a packet sampling technology that often misses the traffic the network analyst wants to see. Over the past few years, the adoption of sFlow has been petering out with more vendors adopting IPFIX. Despite its short comings, some software and hardware platforms, for various reasons, prefer sampling. For this reason, the team of IETF engineers behind IPFIX enhanced the technology to include both packet and flow sampling.

The Rise of IPFIX

IPFIX is the only true standard which means it isn't proprietary. It is in fact owned by all of us in the Internet community. For this reason, vendors can create nearly unlimited elements for unique metrics when a shared 'common' element for what they want to export doesn't exist. Common elements are IDs that are the same across all vendors (e.g. source and destination IP address). If a vendor feels that a particular metric should be a shared element, they can submit a request to the IETF. The advantage to doing this is that collection vendors can build reports that will work across the various vendor platforms.

IPFIX also supports variable length strings. This means that data such as HTTP Host or URL can be exported in an element that isn't a fixed length. Imagine a short URL such as http://www.ravica.com/files/sensorProbe8.pdf being stuffed into a fixed length field that is capable of transporting a URL five times as long. Obviously, empty bytes would be sent resulting in wasted bandwidth and wasted storage space on the collector. NetFlow doesn't allow for this and sFlow... well, probably didn't sample it.

IPFIX for Logs and SNMP

IPFIX is also being used to export event logs, syslogs and other types of machine logs. It allows these messages to be exported in a structured format which shares common elements with more traditional flows. Again, this practice helps ensure interoperability between reporting solutions.

I have also seen data commonly exported in SNMP be exported in IPFIX (E.g. CPU and memory utilization). The IETF has efforts underway to broaden support for more traditional SNMP OID structures.

Now You Know More about IPFIX

Now that IPFIX is the official standard for all flow technologies, even Cisco Systems is making the switch. Their new Application Visibility and Control (AVC) export supports both NetFlow and IPFIX. This new export can include details on connection latency, packet loss, jitter, caller ID, retransmits and more. If however, you want to export the HTTP Host details, IPFIX must be used and now you know why: it's a variable length string.

Due to the richer exports possible with IPFIX, enterprise customers can expect flows stuffed with more details and possibly much higher flow volumes. With customers demanding richer contextual information such as those offered by Cisco AVC or SonicWALL, legacy flow collectors may not be able to handle these new details. For this reason, it could be time to start considering a next generation IPFIX collector.

Learn more by signing up for the Network Security Surveillance Webcast titled: