Extreme Networks IPFIX Support

March 4, 2014 Mike Patterson


I took some time recently to test our NetFlow collector against the Extreme Networks IPFIX export.  The results came back positive with a few interesting highlights.  The first of which I haven’t seen before which is non IP traffic support.

Many vendors that export NetFlow or IPFIX claim layer 2 support in their export.  In my experience this generally equates to exporting MAC and VLAN details related to IP traffic.  What about the customers out there that have legacy protocols on their networks (e.g. Netbeui, IPX, Appletalk, Decnet)?  NetFlow is purely an IP traffic – export protocol.  IPFIX on the other hand is the official IETF standard for all flow technologies including NetFlow.  Even though sFlow is not a flow technology, IPFIX includes the sFlow functions as well.

The Extreme IPFIX support provides in three templates:

  • IPv4 traffic
  • IPv6 traffic
  • Non IP traffic

Having different templates for IPv4 vs. IPv6 is fairly common. The 3rd template for non IP traffic is really a great idea for customers with non IP traffic that still want 100% visibility into the traffic on their network. Because the template doesn’t include source and destination IP addresses, we were able to build reports based on source and destination MAC addresses. VLANs of course are also exported.

The next advantage that I found with this export is the support for a few IANA elements that I haven’t seen any other vendor export.  Those elements are:

  • exportInterface: The index of the interface from which IPFIX Messages sent by the Exporting Process to a Collector leave the IPFIX Device. The value matches the value of managed object ‘ifIndex’ as defined in RFC2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device’s management system is re-initialized, as specified in RFC2863.
  • lineCardId: An identifier of a line card that is unique per IPFIX Device hosting an Observation Point. Typically, this Information Element is used for limiting the scope of other Information Elements.
  • portId:                  An identifier of a line port that is unique per IPFIX Device hosting an Observation Point. Typically, this Information Element is used for limiting the scope of other Information Elements.

Until our next release, you can do some custom netflow reporting to view the data today.  For module switches, I think this also demonstrates Extreme’s commitment to using IPFIX for exporting useful information regarding the switch configuration.  Beyond configuration details, these three elements also empower the end user to perform “group by” reports that can provide additional traffic behavior insight (e.g. traffic isolated to a specific line card).


Another example of Extreme Networks IPFIX support is in there new Purview appliance which provides DPI insight.  Details exported include layer 7 application name as well as latency or round trip time details.  This hardware is capable of supporting up to 100 million flows at 2.56 Tbit/second.

For years I have written about the Enterasys NetFlow support. Our company provided the software that acts as a gateway to get the Dragon IPS logs exported as IPFIX.  I think now that Extreme has acquired Enterasys as well as developed its own native IPFIX export, I think that we can be confident that flow data will play an important role in the company’s future.

The post Extreme Networks IPFIX Support appeared first on Extreme Networks.


Previous Article
Making an Extreme Difference
Making an Extreme Difference

People want to do the right thing, and I’m not necessarily talking only about the ethical or moral thing. L...

Next Article
Looking Back At Network Field Day 7
Looking Back At Network Field Day 7

On the 20th of February, last week, it was the very first time that we at Extreme participated in a... Read...