[j-nsp] Juniper Cflow, IPFix which one

[Paolo Autore]

Juniper does J-flow

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Wednesday, August 08, 2007 01:32
To: Ivan c
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper Cflow, IPFix which one

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)
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp