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 <[EMAIL PROTECTED]> 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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp