On Tue, Jul 12, 2005 at 09:09:22AM -0500, Mark Borchers scratched on the wall:
>
> > I was mostly wondering why it seems that support for NetFlow
> > version 9
> > is so limited in most projects:
> > http://freshmeat.net/search/?q=netflow§ion=projects
> >
> > Is it because it is very new?
> >
> > Or is the situation similar to that of IPv6 or SNMP v3, where
> > the newest
> > version is so much more complicated, that adoption is going
> > to take *a
> > long time* everywhere, and better to stick to the old version for the
> > time being... 'Cause it is more complicated - thats for sure...
>
> <portions deleted for brevity>
>
> My two cents is that, for now at least, v9 is a solution in
> search of a problem.
I think the problem is well defined, I'm just not sure very many
people have that problem. v5 is great for what it does, but it is
clearly extremely limited and very static with no way to address new
protocols and technologies. The ability to add extensions for stuff
like IPv6 and some of the L3-switching cross-over information
(similar to the stuff sFlow is good at) is very useful for those with
a need, but right now "those with a need" is a very small group.
For most of us v5 is great, just as IPv4 is just fine for most of us
(and will continue to be so for a good while).
In theory, that will change some day (but I'm not holding my breath).
> That was even the case to some degree for v8.
v5 is great if you're running exports on your exit routers and one or
two core routers, but if you've got an extremely large and busy
campus where you might have hundreds of L3 devices, full exports on
each one is often not a practical or useful solution. v8 allows basic
analysis to be done "on box" and reduces the export bandwidth while
still allowing some basic stats to be generated. The cost is a great loss
of total information, but in many cases it just isn't needed. I
really don't need six netflow exports tracking one flow as it wonders
across campus, hitting building and backbone routers. Heck, on just
our exit boxes we run about 200M NFv5 records per day. Sifting through
that much data is a big problem, and it would only be worse if we did
exports on all our backbone (never mind building-demarc!) boxes. If
we needed it, v8 at least gives us the ability to do basic stats and
reports without having to deal with (and transport) all the record data.
That said, we aren't using it either. We pretty much just ignore our
internal backbone when it comes to fine-grain resource monitoring.
That said, we'd never run anything but v5 (or some similar very
detailed record style) on our exit boxes. The fine-grain data is
just too valuable, even if it makes for interesting transport and
storage needs.
> But when that time comes, I'm sure
> I'll join you in asking for v9 support!
Well, I think that's the big trick. You don't see much v9 software
support because there is very little v9 hardware support. Last time
I looked even the fancy new sup720 modules for Cisco's 6500 series
doesn't support v9 exports. Very little of their hardware does.
And if you've got nothing that generates v9 exports, there is very
little reason to write software that collects them. I'll also be the
first to admit it has been some months since I've looked at this, so
perhaps someone can comment on more recent product support.
-j
--
Jay A. Kreibich | CommTech, Emrg Net Tech Svcs
[EMAIL PROTECTED] | Campus IT & Edu Svcs
<http://www.uiuc.edu/~jak> | University of Illinois at U/C
_______________________________________________
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
