[j-nsp] Juniper Cflow, IPFix which one

[Richard A Steenbergen]

On Wed, Aug 08, 2007 at 08:54:53AM +1000, Ivan c wrote:
> Hi All,
> 
> Which standard does Juniper do? Sflow, NetFlow, IPFix, CFlow etc..?
> 
> And does anyone have a open source tools to interrogate the
> information out of the Juniper for traffic accounting?

CFlow isn't actually a standard, it's the name of a particular third party 
program which collects NetFlow datagrams (and an old and defunct one at 
that). The only possible reason I can think of for Juniper to use the word 
"cflow" at all is to avoid using the word "netflow" (does Cisco have that 
trademarked or something?).

At any rate, Juniper calls the configuration element "cflowd" but this 
really means the NetFlow protocol. It supports V5 (aka "classic"), V8 
(with flow aggregation), and as of JUNOS 8.3 V9 (aka "the sflow clone"). 
IPFIX is the IETF standardized version (aka "not-Ciscoized") of NetFlow 
V9, which is essentially the exact same thing but with a few minor tweaks 
for non-Cisco enterprise specific templates (which is why it is often 
called NetFlow V10). All of the other versions of NetFlow were weird 
Cisco-specific hacks (for CATOS etc) which have no bearing on anything 
today.

The "other protocol" is sFlow, created by a third party (InMon) many years 
ago. The protocol was a bit dirty, but essentially it kicked NetFlow's ass 
to the curb in every way possible when it came to functionality. InMon 
makes their money selling sFlow collectors to enterprises who can't figure 
out how to do it themselves, but the specification is openly published and 
not "that" complex". NetFlow V9 is infact largely a copy of sFlow features 
and protocol design, using extensible "templates" to pass different types 
of messages, and copying most of the data that sFlow was previously unique 
in being able to export.

Cisco obviously doesn't want to use sFlow because it competes with 
NetFlow, which is their protocol, but I'm not sure why Juniper hasn't 
implemented it. It's possible that InMon charges some kind of obnoxious 
licensing fees for the sFlow agents or name, I'm not sure, but every other 
major vendor who makes routing products (Foundry Extreme Farce10 etc) has 
embraced sFlow. I gave a NANOG presentation on sFlow use/design recently 
(http://www.nanog.org/mtg-0702/presentations/Steenbergen-sflow.pdf), and 
released some free sFlow datagram parsing libs and example analysis code, 
if you want to read more on that subject.

I haven't used NetFlow V9/IPFIX in any detail to see if they've done a 
good enough job copying sFlow, but on the surface it looks like they've 
replicated at least 90% of the functionality (sampling functionality at 
any rate, I kinda like the sFlow counter push :P). It's possible that it 
has, in which case we may see a lot of vendors switching to IPFIX in the 
near future, for the the moment there is a lot of existing deployed base 
using sFlow, especially in non Cisco/Juniper switching-land. Unless there 
is some really specific reason that I'm not aware of (like aforementioned 
obnoxious licensing fees or somesuch), I would encourage everyone to ask 
Juniper to implement sFlow support in addition to V9/IPFIX (especially as 
they grow into the L2 market with the MX platform). Hey, it could happen. 
:)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)