* Re: NetFlow export
2003-03-13 13:46 ` Florian Weimer
@ 2003-03-13 16:45 ` Jakob Oestergaard
2003-03-14 9:32 ` David Luyer
1 sibling, 0 replies; 7+ messages in thread
From: Jakob Oestergaard @ 2003-03-13 16:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Florian Weimer
On Thu, Mar 13, 2003 at 02:46:04PM +0100, Florian Weimer wrote:
> Jakob Oestergaard <jakob@unthought.net> writes:
>
> > You asked for netflow data export. Netramet can give you something
> > similar to netflow (I never used netflow, but from what I hear, netramet
> > is similar only more flexible).
>
> I need the NetFlow data format, not something else.
Ok.
I suspect it's easier to patch netramet, than start a new kernel-based
project.
If Netramet really supports reading netflow data, I guess it would not
be a huge undertaking to implement write support too. But I'm not
familiar with the Netramet source - really, you should look at it
yourself or ask the developers.
>
> > With 10 lines of Perl you could do full ASN-1 ;)
>
> NetFlow is not based on ASN.1.
No you said that :)
> It's a completely different format (an
> industry standard which is implemented by quite a few vendors).
Ok
>
> > Point being; if what you want is flow information from a Linux router,
> > excellent user space software (both "meter" and retrieval/filtering
> > tools) already exist for that.
>
> I fear the performance impact of copying all packet headers to user
> space.
I understand.
But I don't think you need to worry - how much bandwidth and how many
flows are we looking at here?
Several million flows a day is no problem for an aging PIII 550 (running
with full BGP).
Netramet allows you to define what makes a flow - so depending on your
needs, you can set the detail versus performance pretty much as you
please. It has a simple rule language (SRL) to define these filtering
rules.
>
> > If you want something else, then I have completely misread your mails.
> > Please elaborate, in that case :)
>
> I'd like to see something which has virtually no impact on forwarding,
> so that it's a no-brainer to enable it. I doubt copying all the
> packet headers to user space falls into this category.
Well, netramet is not going to do the routing. Whatever netramet does,
the packets will flow.
Worst case, netramet is going to miss a flow. If you did it in the
kernel instead, I guess you could either do it the same way, or make the
router drop packets when load gets too high. I think the current
solution works well. For the loads that I have seen - maybe you have
other kinds of loads...
Netramet allocates a buffer it uses for holding the flows. If the
"meter" is not emptied frequently enough, netramet may decide to drop
the oldest/smallest flows, to make room for new ones.
This buffer, on a relatively busy router, can easily be 50-100 MB.
This, too, is a good reason to keep it in user space I think.
The kernel memory footprint is bad enough with the routing tables that
full BGP causes.
I think that you should measure and experiemnt - verify that there
really is a problem with a user-space solution, before even thinking
about doing something relatively complicated (and already existing) in
kernel space.
Wheels don't necessarily turn faster just because you re-invent them in
the kernel ;)
Well that's my 0.02 Euro, at least.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: NetFlow export
2003-03-13 13:46 ` Florian Weimer
2003-03-13 16:45 ` Jakob Oestergaard
@ 2003-03-14 9:32 ` David Luyer
1 sibling, 0 replies; 7+ messages in thread
From: David Luyer @ 2003-03-14 9:32 UTC (permalink / raw)
To: 'Florian Weimer', linux-kernel
Florian Weimer wrote:
> Jakob Oestergaard <jakob@unthought.net> writes:
>
> > You asked for netflow data export. Netramet can give you something
> > similar to netflow (I never used netflow, but from what I
> > hear, netramet is similar only more flexible).
>
> I need the NetFlow data format, not something else.
NetFlowMet is the NetFlow module for netramet. But it's only a
receiver, not a transmitter.
However, 'ntop' can generate NetFlow packets from a Linux system,
using libpcap.
I suggest you read http://www.switch.ch/tf-tant/floma/software.html
> > With 10 lines of Perl you could do full ASN-1 ;)
>
> NetFlow is not based on ASN.1. It's a completely different format (an
> industry standard which is implemented by quite a few vendors).
NetFlow interacts with SNMP a little though. The interface ID numbers
in NetFlow come from the SNMP interface index table.
> > Point being; if what you want is flow information from a
> > Linux router, excellent user space software (both "meter" and
> > retrieval/filtering tools) already exist for that.
>
> I fear the performance impact of copying all packet headers to user
> space.
It's only the headers, not the packets.
NetFlow in Cisco routers is a route caching path which happens to
keep counters that it can export as flow export packets. It can
also be used to do things such as caching policy routing (reducing
ACL lookups and so on). But chances are there are patents covering
the use of NetFlow route caching.
> > If you want something else, then I have completely misread
> > your mails. Please elaborate, in that case :)
>
> I'd like to see something which has virtually no impact on forwarding,
> so that it's a no-brainer to enable it. I doubt copying all the
> packet headers to user space falls into this category.
Maybe you should try ntop and see what impact it has (preferably in a
test lab first, if you have a performance testing lab)? If the impact
is too high, you could consider an alternate approach (eg, using some
form of kernel IP accounting and periodically scanning the accounting
table and exporting the flows as NetFlow packets).
Personally I considered once implementing a kernel *receiver* for
NetFlow packets as receiving NetFlow packets is an extremely critical
application for me. However in the end I wrote a userspace NetFlow
receiver that's a mix of assembler and C (but not using libc) and
is careful to accumulate data into 128k blocks before writing it to
a RAID array optimized for 128k writes, and it can receive an insane
amount of NetFlow data (compared to older utilities running on
mid-range DEC Alpha or Sun systems on commercial operating systems,
which had problems keeping up with one busy router, this runs on an
aging Intel ISP2150 and collects from over 50 busy routers, still
at low load) so I never had to actually go down the kernel path.
David.
^ permalink raw reply [flat|nested] 7+ messages in thread