Our IPFIX collector has seen it all and helping other NetFlow vendors keeps us on our toes. One of the biggest things we encourage companies to do is to avoid NetFlow v9 for anything that isn’t EXACTLY like Cisco. If the vendor wants to export URLs or something unique that Cisco doesn’t export in NetFlow yet, we recommend using IPFIX.

The IPFIX standard information elements are referenced in the IPFIX RFC 5102 which specifies a range of identifiers from 1 to 32767. Within this range, Information Element identifier values in the sub-range of 1-127 are compatible with field types used by NetFlow version 9 RFC 3954. Notice on page 23 in RFC 3954 that it stops at element 79.  This is because 79 was all the element ids that existed when the RFC was written.  Cisco simply added the following paragraph to allow for extending the protocol:

    When extensibility is required, the new field types will be added to
    the list.  The new field types have to be updated on the Exporter and
    Collector but the NetFlow export format would remain unchanged.

On July 11th, 2011, the IPFIX Cisco Vendor Specific Information Elements draft was posted which describes some additional Information Elements of Cisco Systems, Inc. that are not listed in RFC3954.  Thank you Cisco!

Sometimes when we receive a new NetFlow or IPFIX capture to test, Cisco can be thought of as a haystack and finding the new field types on their web site can be like looking for a needle!   The above draft helps reduce the amount of searching we have to do.

finding NetFlow information elements

The hay stack analogy is especially true if all you have is the numeric value of the information element id. For example if I know that element id 89 is being exported and I put “NetFlow 89” in the search bar I get many pages of hits most of which are not helpful. If I happen to know that Cisco called the field “FORWARDING_STATUS” I can add that to the search string and pretty easily find it.  Long story short, Cisco can define what they like in NetFlow. After all, they own NetFlow. With some persistence you can figure out what a new ID means.

If you see RESERVED in the IPFIX IANA list we may still decode the value. These values are typically all UPPERCASE with underscores between words as this is the style Cisco uses. You will see this in our IPFIX reporting solution as well.

Information Element Format


When conflicts arise between NetFlow and IPFIX, we use the IPFIX field names to save data. This allows our IPFIX reporting to deal with inconsistencies in the naming conventions. In our NetFlow solution, the IANA IPFIX element names trump the Cisco NetFlow element names. We only use NF_* or other Cisco names when no standard name exists.

Time stamps : IPFIX and NetFlow element names conflict
The IPFIX observationTimeMilliseconds column is the same as the Cisco ASA NF_F_EVENT_TIME_MSEC value. Our NetFlow Collector labels it observationTimeMilliseconds because of what I stated above (i.e. IPFIX is the standard).

In addition to the range 1 – 127, NetFlow (not IPFIX) values greater than 32767 are sometimes used by Cisco and others in order to add non standard elements to NetFlow v9. This works because values above 32767 in NetFlow have no standard meaning and WILL NEVER have a standard meaning because this range is reserved for vendor extensions in IPFIX.  Furthermore, the area above 32767 in NetFlow is not managed by the IANA standard because it is still owned by Cisco!

NetFlow v9 has no option for vendor extensions hence, if your company needs to use NetFlow v9 with nonstandard fields above 32767 you sort of enter the wild west. Why? Your work could get trumped by Cisco or another vendor. This is why we encourage vendors such as Sonicwall, Juniper, nProbe and others to make the switch to IPFIX. BOTTOM LINE: If you want to export something that doesn’t have a standard information element, switch to IPFIX.

A word about PENs
Similar to Public and Enterprise SNMP OIDs, vendors can use the same values because their Vendor OID makes the element unique. For example,
our Exchange Log Analyzer ‘Mailinizer’ exports Microsoft Exchange Event Logs in IPFIX datagrams. Plixer’s Enterprise ID is 13745.

To find the PEN for any vendor refer to the IANA enterprise numbers. Examples are:

9     Cisco Systems
13745    Plixer
35632    nTop

In IPFIX there is a 16 bit field where the element ID is specified.  If the first bit is a 1, then the following number above 32767 can be anything that vendor wants and it can conflict with another vendor because it is uniquely identified by the PEN (e.g. Plixer).  If the first bit is set to a 0, then the following number up to 32767 must adhere to the IPFIX standard and all vendors must use the field in EXACTLY the same way.

TO BE CLEAR: A push for IPFIX Support
The problem with using the NetFlow v9 extensions above 32767 is that there is no governing body except Cisco to allocate identifiers. If two vendors (or even two groups at the same company) happen to pick the same ID for different types then all bets are off. We maintain a list of the extensions Cisco is already using above 32767, contact me to see it, if you find conflicts or need us to add entries.


Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.


Big Data

Sankey Flow Graph

One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the…

Leave a Reply