The question of the “big difference” between NetFlow vs IPFIX is something of a curious one for several different reasons. First and foremost, IPFIX itself is directly spawned from NetFlow v9 and, further, several individuals who worked on v9 also worked on IPFIX, which is even considered NetFlow v10 for all intents and purposes! For the curious, IPFIX stands for “IP Flow Information eXport,” and is an IETF standard specifically meant to open up flow to a broad range of vendors more easily.

That said, there's a reason that it became IPFIX and not simply “NetFlow v10”. It's worth emphasizing up front that IPFIX is also beautifully backwards compatible with v9 traffic, having special reservations in its element fields to be sure that said fields are available for v9 NetFlow information even when working primarily via IPFIX. IPFIX was fueled heavily by the desire of vendors to push away from the Cisco-driven standards and forced rigidity of NetFlow to provide a much more open and flexible flow gathering datagram and environment.

Difference between IPFIX and Netflow

The biggest and most glaring problem with v9 and where IPFIX soars way ahead comes in its flexibility. NetFlow v9 can do a lot of great work for monitoring and sending data but as soon as you get into wanting to send anything that Cisco itself didn't build into the NetFlow standard, it gets tricky. There are ways to do it, and it definitely does have some level of expandability, but it becomes something of a kludge job of assigning new values, having to define them elsewhere, and then go digging around wildly with your collector in an effort to find, isolate, identify, and reserve that information. It's not really all that hard, but it's ultimately a waste of time when you simply need to deliver something like URL information or any other proprietary or specific data not build into NetFlow v9. Put simply, if you need to snag any data that isn't standard with v9, you would be far better off to jump straight to IPFIX!

On the purely technical side there's a handful of definite nuances between the two – a small change in semantics shifts the “IN_BYTES” from NetFlow v9 to “octetDeltaCount”, which some find more accurate since flow data isn't really “inbound bytes” or data and can be kinda misleading. NetFlow v9 has a set of 79 field types defined, whereas IPFIX has the same 79, for backwards compatibility, but then goes all the way from there up to 238. That's a lot more information and an enormous amount of room for getting any and all the flow data you could want! IPFIX also allows for variable length fields, whereas NetFlow is a lot more rigid in the nature of its fields, which can make transmitting information that varies wildly, or just happens to change a lot in expected format (URLs, usernames, etc.), a lot easier. It is worth pointing out that NetFlow v9 does support a “Flexible NetFlow” that aims to address at least some if not most of these concerns and, arguably, it does a good job. Funny enough, Flexible NetFlow is not actually limited to NetFlow only and is really more of a generalized extension/configuration and can even be applied to IPFIX to provide some enhancements in niche situations. With that said, it does require additional setup and configuration in any case, which then begs the question of why not simply go with IPFIX from the start?

And finally, the big one of these technical differences, IPFIX has room for a vendor ID, which allows you to assign a specific identifier along with pretty much ANY bit of data. This enables the capturing and gathering of almost any sort of data, including far, far more than simple SNMP data. It should be obvious at first glance just how much flexibility this one little change provides, but it really can't be overstated or emphasized enough. The downside, of course, is that with flexibility comes some level of incompatibility – too many non-standard changes or adjustments can leave things a bit confusing, but at the same time it'd be unwise to take a heavily customized IPFIX-based set of software and hardware from one environment and slap it right into an entirely different one anyways, so the point can be made that this isn't too much of a downside. Issues generally crop up in the case of sharing IPFIX data between separate locations with different configurations or when sharing data in general, but even with that said there are ways to export and tidy up this data for sharing purposes, so again it's hard to say if this is a big lynchpin or not with any certainty.

IPFX and Netflow Ports

By default, IPFIX listens on UDP port 4739 while NetFlow v9 tends to listen on 2055, 2056, 4432, 4739, 9995, 9996, and several others. In either case the ports can be configured as needed and are not set in stone, so it doesn't create a major barrier regardless. Thankfully, when it comes to compatibility, there's not much trouble. Cisco's NetFlow is compatible with a decent range of vendors, and by merit of being heavily NetFlow based, yet more open-ended, IPFIX is just as compatible and grows in compatibility with each generation of devices going forwards. Just a few of IPFIX's major vendors include Cisco Systems, Citrix, Juniper, Plixer, SonicWall, VMWare, and more, so it's obviously not a small player or difficult to find supported on a device.

Ultimately the question of NetFlow vs IPFIX tends to be a relatively easy one – there's few reasons not to simply jump on IPFIX and get it setup and running for your particular environment, but there may well be some situations where the slightly newer-format just isn't worth all the hassle and, what's more, the added functionality offered by IPFIX may not really provide a lot of value to your network environment! Both of them are fairly powerful for enabling data collection and analysis, but in most ways IPFIX can pull ahead depending on specific needs – though with that said, some environments may already have long-standing NetFlow based solutions such that the time required to change things up just isn't worth the gain for what IPFIX adds, in which cases simply bringing Flexible NetFlow into the mix may be ideal.

At the end of the day the two are certainly comparable, especially with Flexible NetFlow added on top of NetFlow v9, but there's a definite and strong push for IPFIX use and availability from vendors eager to pull away from Cisco standards and work with something much more generally accessible and open.

James Cox is the Editor at ITT Systems and has a Long History in the IT and Network Engineering Field. He Boasts a long list of Credentials ranging from CompTIA Certifications up to Cisco and VMWare points on his Resume.