Exporting NetFlow or IPFIX

Posted in cisco ASA, Cisco NetFlow, IPFIX on December 30th, 2012 by mike@plixer.com
Exporting NetFlow or IPFIX

Is your engineering team trying to decide if you should be exporting NetFlow or IPFIX? This is the area of the technology where many first time vendors make mistakes. Implementing NetFlow or IPFIX is not difficult. But when programmers rely solely on RFCs as an implementation resource, the result is usually an export that many flow reporting vendors won’t support.  For this reason, this blog is largely dedicated to engineers who either want to export these technologies correctly or who need to troubleshoot what is wrong with an export they have been asked to look at.

Choosing NetFlow or IPFIX

First of all, unless the vendor name wanting to export flows begins with C-I-S-C-O, IPFIX should be the choice for the new exports.  Any company is free to export NetFlow and this is not necessarily a bad choice, except flow exports almost always lead to exporting something unique that isn’t defined in NetFlow and for this reason, vendors outside of Cisco should be exporting IPFIX.

Private Enterprise Numbers

In the world of SNMP there is MIB II and the Enterprise MIB. Standards-based SNMP values are under 1.3.6.1.2.1. Think of this as the basic export available in NetFlow v5. An example of this in SNMP is sysName, sysUpTime, sysContact, sysLocation and sysDescr. Pretty much all vendors supporting SNMP provide details for these objects.  In a similar fashion, most vendors exporting NetFlow export details on the source and destination IP address, ports, protocols, ToS, autonomous systems, subnet mask, interfaces and next hop.  These vendors export these details usually with exactly the same field type. In RFC 5102 and in a few updates that followed, IANA-IPFIX  defines over 350 field types that can be shared amongst vendors.  If what a vendor wants to export isn’t defined by the IETF yet, the vendor must reserve some elements under their private enterprise number.  The vendor can also choose to pursue work in the IETF so that the public IPFIX may be used.

In SNMP, enterprise-enhanced values are under the Enterprise OID 1.3.6.1.4.1. IPFIX works in a similar way. In fact, oftentimes the same IANA registered Private Enterprise Numbers (PEN) are used.  The private space is where vendors like Astaro, Citrix, ntop, Palo Alto Networks, Plixer, and SonicWALL export flow details related to things like email addresses, latency, URLs, packet loss, caller ID, jitter, etc.

A Word about Private Enterprise Numbers (PEN)

Similar to enterprise SNMP OIDs, vendors can use seemingly identical values because their Vendor PEN makes the element unique. This is explained in better detail below. To find the PEN for any vendor refer to the IANA enterprise numbers. Examples are:

  • 9 Cisco Systems
  • 52 Enterasys
  • 8741 SonicWALL
  • 13745 Plixer
  • 32473 Example
  • 35632 NTop

To request a PEN from IANA, visit this URL: http://pen.iana.org/pen/PenApplication.page
IPFIX takes essentially the same approach including using the same PEN used in SNMP. Both standard and enterprise specific Information Elements (IE) are in the range of 1-32767 in a 16 bit field. If it is an enterprise specific IE field, it is followed by a 32 bit field for the PEN.

The existence of the PEN field is flagged by setting the high bit in the IE.  In this document we will note standard IEs found in IANA by their IE identification number. Below, enterprise specific IEs are noted with their IE number followed by a dot and the PEN. Consider the following simplified IE numbers, for example:

  • IANA
    • 140    mplsTopLabelIPv6Address
    • 141    lineCardId
    • 142    portId
  • Plixer
    • 140.13745    MailboxDisplayName
    • 141.13745    TotalItems
    • 142.13745    Size

It may appear that IEs, 140, 141 and 142 are used twice and in a way they are.  However because the 2nd set is Plixer specific, the high bit has been set to a one.  As vendors, the ability to have free reign in how we define elements allows us to innovate.

One of the more creative uses of flow technology we implemented was in our syslog to IPFIX gateway solution called the Flow Replicator. This appliance can convert any log (i.e. not just syslog) to IPFIX for reporting and correlation with NetFlow.  For example, we can correlate NSEL from the Cisco ASA to the syslogs exported by the same Cisco ASA.  We have also exported proxy logs which empowers admins to look up URLs in NetFlow exports. IPFIX is the way to go.

 

Michael Patterson
Founder and CEO

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.
Tags: , ,