On Thu, Mar 13, 2003 at 12:07:00PM +0100, Florian Weimer wrote:
> Are there any patches which implement kernel-based NetFlow data
> export?
Netramet works very well - it's userspace (and very flexible indeed).
No need to clutter the kernel with an SNMP stack too, if you ask me.
--
................................................................
: [email protected] : 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}...............:
Jakob Oestergaard <[email protected]> writes:
> On Thu, Mar 13, 2003 at 12:07:00PM +0100, Florian Weimer wrote:
>> Are there any patches which implement kernel-based NetFlow data
>> export?
>
> Netramet works very well - it's userspace (and very flexible indeed).
According to the documentation, it can receive NetFlow data and
process it, but it cannot generate such data.
> No need to clutter the kernel with an SNMP stack too, if you ask me.
NetFlow doesn't use a complicated packet format and is not based on
SNMP. You can parse version 5 or 7 packets in 10 lines of Perl code,
using a few calls to "unpack".
On Thu, Mar 13, 2003 at 12:57:08PM +0100, Florian Weimer wrote:
> Jakob Oestergaard <[email protected]> writes:
>
> > On Thu, Mar 13, 2003 at 12:07:00PM +0100, Florian Weimer wrote:
> >> Are there any patches which implement kernel-based NetFlow data
> >> export?
> >
> > Netramet works very well - it's userspace (and very flexible indeed).
>
> According to the documentation, it can receive NetFlow data and
> process it, but it cannot generate such data.
I never used it to receive netflow data.
I used netramet to generate flow information on a linux-based backbone
router, and to periodically move the flow information to another node
for batch processing/analysis.
I used the netramet tools to extract that information from the netramet
"meter" (the flow measurement daemon running on the router), for storage
on the remote accounting/processing machine. Some custom Perl scripts
process the flow information thereafter.
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).
>
> > No need to clutter the kernel with an SNMP stack too, if you ask me.
>
> NetFlow doesn't use a complicated packet format and is not based on
> SNMP. You can parse version 5 or 7 packets in 10 lines of Perl code,
> using a few calls to "unpack".
With 10 lines of Perl you could do full ASN-1 ;)
Netramet uses SNMP for the data transport - and I am very much surprised
if Cisco does not use SNMP - but again, I did not use netflow so I
wouldn't know.
In any case, to the "end user", it's as simple as calling a tool saying
"get me my data" - whether it's SNMP based or not.
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.
If you want something else, then I have completely misread your mails.
Please elaborate, in that case :)
--
................................................................
: [email protected] : 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}...............:
Jakob Oestergaard <[email protected]> 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.
> 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).
> 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.
> 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.
On Thu, Mar 13, 2003 at 02:46:04PM +0100, Florian Weimer wrote:
> Jakob Oestergaard <[email protected]> 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.
--
................................................................
: [email protected] : 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}...............:
Florian Weimer wrote:
> Jakob Oestergaard <[email protected]> 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.