Real World Throughput Testing (by Tony Fortunato)
When to Measure Your Network Performance? (by Tony Fortunato)

I wish for a NetFlow ASIC like Enterasys (by Michael Patterson)

Author Profile - Michael Patterson is currently the Product Manager of Scrutinizer NetFlow and sFlow Analyzer at Plixer International. Prior to Plixer Michael worked for Cabletron Systems as the Director for outsourced network management.

Plixer International develops and markets network traffic monitoring and analysis tools to the global market. All of the tools are built from the ground up with valuable feature sets and ease of use in mind. Plixer tools have been used to analyze and troubleshoot irregular traffic patterns by IT professionals with some of the largest networks in the world, such as CNN, The Coca-Cola Company, Abercrombie & Fitch, Lockheed Martin, IBM, Regal Cinemas, Raytheon, and Eddie Bauer.

WoW - I wish for a NetFlow ASIC like Enterasys!!

By: Michael Patterson

I’d like to see a company develop and sell a chip like sFlow for NetFlow. I occasionally here about how NetFlow is ‘done’ with software is and CPU intensive while sFlow is done in hardware.  This is true and false.  A few companies don’t take sides in the [NetFlow Vs sFlow]  debate.  One of them is Enterasys, which is the only vendor outside of Cisco with a NetFlow capable switch.

The Enterasys B series switch supports sFlow and targets the consumer base that is looking for a less expensive switch.  On the other hand, the Enterasys N Series switch supports NetFlow using hardware (i.e. they designed and build their own NetFlow ASIC).  It can be considered less expensive when compared to Cisco’s NetFlow capable switches. EnterasysSSeriesFamily

In [their documentation] they claim: A distinct Enterasys advantage is flow-based ASIC capabilities that collect NetFlow statistics for every packet in every flow without sacrificing CPU or switching performance.”   It collects and exports flow data at gigabit speeds!

The Enterasys NetFlow ASIC is capable of collecting 9,000 flow records per second, per blade on any module. This is a NetFlow generation capability greater than most other NetFlow capable appliances on the market as it can send over 70,000 flow records per second in a fully populated chassis.  Because of these numbers and the growing demand for NetFlow capable hardware, it is understandable that we have to pay a bit more for a switch with this capability not to mention its other features.

The [Cisco Nexus 7000]  also performs NetFlow using hardware. It claims “Up to 500,000 (with 95 percent utilization efficiency) cached flows for forwarding engine”, but I’m not sure what this means.  Note: 80% of the companies in the world with gear that is capable of exporting NetFlow can only export at maybe 10,000 – 20,000 total flows per second (i.e. 1 million flows / minute) combined from all routers and switches.


Most [NetFlow analyzers] don’t have a problem keeping up with these rates.  Cisco by the way recommends [NetFlow sampling] when full NetFlow collection isn’t possible.

A Market for a NetFlow Chip

Since the next generation of NetFlow called Flexible NetFlow is being used now to export more than flow information (e.g. syslogs, summary statistics, interface names, packet captures, etc.) I think it is high time that a company develop a NetFlow or IPFIX (NetFlow proposed standard) capable ASIC and make it available in the same way [Inmon] sells the sFlow chip to switch vendors. Here is my wish list for the chip:

Per Interface Chip:

· support for NetFlow v5 and v9 ingress

· support for NetFlow v9 egress and or Flexible NetFlow

· support for bidirectional flows RFC 5103 using IPFIX which is different from what the Cisco ASA exports

· support for exporting SNMP trap like information and pretty much any OID.

· support for latency collection by watching TCP flag exchanges like the [nprobe]

· support for an active timeout at 60 seconds and inactive timeout at 15 seconds (Cisco Guidelines)

· support for performing deep packet analysis to:

o    export flows or packets that match a pattern

o    identify applications after a series of packets behave like a known application (e.g. Skype) Cisco already does this with NetFlow NBAR. Another company to be announced is doing something similar on a firewall.

o    allow us to configure the above with a series of SNMP set commands.

Switch Core Chip:

· support for exporting syslogs and SNMP traps

· support for exporting CPU, Memory usage as well as any other SNMP OID

· support behavior analysis and watch flows for strange traffic patterns.  Most vendors already support this albeit not with NetFlow at the switch. The messages should be exported in IPFIX or Flexible NetFlow.

· support for SCTP and IPv6 [link] to secure the data when exported off to the NetFlow or IPFIX collector.

Why Support so much NetFlow

The reason why vendors should support NetFlow or really IPFIX is because it is more efficient than older technologies such as SNMP which involve polling.  NetFlow is a passive technology.  Syslogs on the other hand don’t involve polling, but can be verbose and chatty regarding the volume of data they can send.  With NetFlow or IPFIX multiple syslog messages can be stuffed in a single datagram.  We see the Cisco ASA already exporting syslog like messages with the NSEL v4 Denied no XLATE template.

Mind the Templates

Then there is the issue of templates, proper formatting and linking between templates or keys to the related flow template is imperative. Make sure the templates are sent out every few minutes. I won’t digress on this, but it is very important to think this through. We have worked with several vendors that have had to put some serious thought into when and when not to export a new template. 


NetFlow and IPFIX technologies are ripe for 3rd party involvement.  Cisco has an entire team dedicated to the flow technologies (i.e. IPFIX and Flexible NetFlow).  Are there any entrepreneurs out there interested in running with the idea of creating a NetFlow or IPFIX ASIC for resale to switch manufacturers?  I’d like to help, but we want to focus on NetFlow collection and analysis.