richb-hanover / flow-tools Goto Github PK

Is this supported?.

If there is a set of steps i need to follow to get a 64 bit compiled version of 
flow-export and flow-tools pkg in general on freebsd amd64.

Currently the exisiting flow-export takes a very long time...and hence i am 
trying to see if 64 bit compiled version helps in some way

flow-tools release: flow-tools-0.66

What steps will reproduce the problem?
1. start flow-fanout or flow-capture
/md/binarios/bin/netflow/flow-fanout 0/0/2056 0/0/2055 0/212.31.32.163/2055
/md/binarios/bin/netflow/flow-capture -z0 -N0 -V5 -n295 
-w/md/dumper/files/flow-capture 0/0/2055

2. the syslog shows:

May 20 12:20:55 dmdnet01 flow-fanout[4866]: ftpdu_seq_check(): 
src_ip=10.17.32.32 dst_ip=0.0.0.0 d_version=5 expecting=22030939 
received=3648399742 lost=3626368803
May 20 12:20:55 dmdnet01 flow-fanout[4866]: ftpdu_seq_check(): 
src_ip=10.17.32.32 dst_ip=0.0.0.0 d_version=5 expecting=3648400432 
received=3648400462 lost=30

What version of the product are you using? On what operating system?

HP-UX HP01 B.11.31 U ia64 4219704302 unlimited-user license


Please provide any additional information below.

What steps will reproduce the problem?
1. What's the flow rate supported per second in flow-tools
2. And what is the suggested hardware configuration for various flow rates
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Thanks,
Ram

What steps will reproduce the problem?

1. Enable flow for multiple routers, In my case 21 router to a same destination 
server & same port (like, flow-capture runs on 2056 port and capture flow data 
for all routers) 
2. When i ran flow-header for the completed flow file, i could see lost flows. 
Because of this the utilization reports are getting lot of discrepancies when 
compare to real time utilization
3.

What is the expected output? What do you see instead?
I need to capture flow data from more then 100 devices on a same server with 
same flow-capture port with out any loss. Please help me to implement this..

What version of the product are you using? On what operating system?
I am using flow-tools-0.68.5.1-1.el5 on Redhat 5.9 64 bit operating system..

Please provide any additional information below.

Thanks in Advance,
Ram

I am trying to get Cflow working with flow-tools from this site
http://flow-tools.googlecode.com/files/flow-tools-0.68.4.tar.bz2

Although flow-tools install I am unable to compile Cflow and get that
working which is really frustrating.

I keep reading everywhere that:

 This assumes you have flow-tools installed on your system fully, 
including headers
 and development libraries. This is the only supported way to use Cflow.

I am stuck - please can anyone help me - how exactly do I install the
headers and development libraries?

There is an example on data:
:unix_secs,sysuptime,dpkts,doctets,first,last,srcaddr,dstaddr,srcport,dstport,pr
ot 
4699318,317952454,11,1767,317935544,317935544,172.16.0.40,109.205.246.211,49479,
8010,6

But problem is in unix_secs value. Documentation for netflow v5 says that 
unix_secs is current count of seconds since 1970, but 4699318 is about 4 days 
only.

What steps will reproduce the problem?
1. Use one instance of flow-fanout with a filter and one without a filter
2. Have each instance send data to a different instance of flow-capture.
For simplicity, flow-capture A gets the unfiltered data and flow-capture B
gets the filtered data.
2. View the filtered and unfiltered data captures with flow-cat

What is the expected output? What do you see instead?
I would expect to see the flows that match the filter in the data collected
by B, but they aren't.  If I run flow-cat | flow-nfilter | flow-report on
the unfiltered data collected by A, using flow-nfilter with the same filter
as one of the instances of flow-fanout, I see the filtered data reported. 
If I look at the data captured by flow-capture B, I see no data collected.

What version of the product are you using? On what operating system?
RHEL5, flow-tools 0.68.4.2

Please provide any additional information below.
This appears to have been a problem before with flow-tools 0.67:
http://mailman.splintered.net/pipermail/flow-tools/2004-January/001853.html

Maybe the fix was overwritten?

What steps will reproduce the problem?
see following

What is the expected output? What do you see instead?
some flows from 01-May are printed with a 20-Jun date

What version of the product are you using? On what operating system?
flow-tools-0.68.4, RHEL 5 on x86_64

Please provide any additional information below.
ftltime() hasn't changed since the ftio.c library file was created in 0.40,
but produces an incorrect result for maybe 10 minutes every 49.7 days
(unless your routers are rebooted at least this frequently).

This was noticed when I recently changed the code I use to process each
month's worth of flows to record the earliest and latest flow timestamp
seen. The earliest timestamp seen in the May flows was just before midnight
on Apr-30, as expected. However the latest flow seen was from Jun-20.

It was unlikely flow records/files had gotten mixed up since that date was
in the future. Now I was using a slightly modified version of ftltime()
that produced a result like struct fttime except there was a third field
for microseconds which I had a one-off interest in, but found they were
always zero from our routers.

I soon narrowed the problem down to flows occuring around 9:23PM on May-01.

I didn't think there was a problem with my code as the changes were so
small, and this was confirmed by grepping the output of flow-print -f 2
for '0620' with results like
  00e0 203.100.24.26    0000 203.100.25.255    11 89   89    18   1404
   0620.14:25:45.188  0620.14:25:55.160      9.972 78  00 10
  004d 203.100.30.221   0000 203.100.30.255    11 8a   8a    2    458
   0620.14:25:51.380  0501.21:23:08.080      3.996 229 00 10

From printing out the 4 values supplied to ftltime() when anomalous
results were produced, it was clear this happened just after sysUpTime
rolled-over from 4billion to a small number. ftltime() was producing
a difference close to 2^32 rather than the much smaller number it should
be. 2^32 milliseconds / 1000 / 86400 is about 49.7 days, which fits since
May-01 to Jun-20 is 49-50 days.

I believe I've fixed this problem in my version of ftltime(), but added
code to print out lines like the following whenever my result was diff-
erent to the ftltime() library version and these lines happen only when
the library version is producing Jun-20 dates, i.e. my version behaves
the same in all other cases.
 sys 19200, secs 1209641007,  msecs 184,  First 4294952156,  Last 19168     
   First  lib_ftltime  0620.14:25:40.140,  my_ftltime  0501.21:22:52.844  
    Last  lib_ftltime  0501.21:23:27.152,  my_ftltime  0501.21:23:27.152  

As it turns out, I also checked the flow duration calculated directly
from Last-First against that of the ftt structs for First and Last for
both my version and the library version and both were always correct.
You wouldn't normally expect this from buggy code but it probably makes
perfect sense if you analysed the way way unsigned ints behave.

Here's my corrected code, and while I wouldn't expect all the comments
to make it into you repository, I think there needs to be something
indicating there was an issue in the past and that people should only
make changes with some care; in particular testing against cases when
sysUpTime has rolled-over while t hasn't.


/*
 * [DMT 13-Jun-2008] corrected version of based on ftltime()
 * ftltime returns a struct fttime = secs - sys + t
 * But fails to handle the case when sys has recently rolled-over 2^32
 * so sys is a small uint32_t value while t is close to 2^32 milliseconds.
 * The result is about 47 days wrong.
 *
 * The approach used to fix this is to treat (sys - t) as a signed number
 * which we expect to be quite small so we don't worry about corner cases
 * like -2^31.
 * 
 * I was guessing there would be a fixed relationship between sys and t,
 * so either sys or t would roll-over first. I haven't really looked but
 * suspect First is always behind sys. However while Last is normally
 * behind sys:
 *   sysUpTime 17660, unix_secs 1209641005,  First       1740,  Last  1740      
 * here's a counter-example from the same 5 minute flow file
 *   sysUpTime 13660, unix_secs 1209641001,  First 4294965144,  Last 14716
 *
 * NB the case of Last>sys did not produce an error with the original code
 * because the arithmetic was done in 2 stages, both involving the value
 * divided by 1,000, and hence not subject to roll-over. The problem only
 * happens when only one of sys and Last have rolled-over. Perhaps a correction
 * factor of 2^32/1000 could have been applied to both the seconds and
 * millisecond values.
 *
 * NB an alternative approach might be to use larger signed types, but the
 * binary '%' operator behaves as a mathematical mod operation for positive
 * values, i.e. for unsigned types. However "if either operand is negative,
 * the behaviour will be machine-dependent":
 *   C: A Reference Manual 4th ed, p202.
 * The best approach might well be to use doubles as they'll easily handle
 * 32 seconds bits + 10 milliseconds bits.
 * 
 */
struct fttime my_ftltime(uint32_t sys, uint32_t secs, uint32_t nsecs, uint32_t 
t)
{

  uint32_t diff, diff_s, diff_m;
  struct fttime ftt;
  int diff_was_negative = 0;

  /* unix seconds/nanoseconds to seconds/milliseconds */
  ftt.secs  = secs;
  ftt.msecs = nsecs / 1000000L;

  /* sys and t are in milliseconds */
  diff = sys - t;

  /* we don't expect the unsigned difference to be anywhere near 2^31  */
  /* but allow +/- 2^31, approx 2 billion anyway                       */
  if (diff > 2147483648) {
    diff_was_negative = 1;
    /* negate to have an absolute value before deriving secs/msecs     */
    diff = -diff;
  }

  diff_s = diff / 1000;
  diff_m = diff % 1000;

  /* calculate ftt -= diff */
  if (diff_was_negative) {
    /* subtracting a negative value means add */
    ftt.secs  += diff_s;
    ftt.msecs += diff_m;
    if (ftt.msecs >= 1000) {
      /* handle overflow */
      ftt.msecs -= 1000;
      ftt.secs++;
    }
  } else {
    /* simply subtract */
    ftt.secs -= diff_s;
    if (ftt.msecs < diff_m) {
      /* handle underflow */
      ftt.msecs += 1000;
      ftt.secs--;
    }
    ftt.msecs -= diff_m;
  }

  return ftt;

} /* ftltime */

What steps will reproduce the problem?
Find below. 

What is the expected output? What do you see instead?
Works great on i386.  Very big memory leak on 64bit. 

What version of the product are you using? On what operating system?
FreeBSD 7.1 amd64 release. flow-tools 0.68.4.1

Please provide any additional information below.
All the BSD(amd64) people will appreciate the patch. 

Thanks.

What steps will reproduce the problem?

1. Let a flow-capture or flow-fanout instance listen on a specific IP/port
2. Configure a Cisco router to send NetFlow v9 data to this IP/port


What is the expected output? What do you see instead?
 - flow-capture: Nothing is captured and saved into the file
 - flow-fanout: No NetFlow packets are sent to the defined targets


What version of the product are you using? On what operating system?
 - flow-tools version 0.68
 - Used on Ubuntu 10.04 32Bit


Logfile entries which occur repeatedly:
 - flow-capture[27707]: ftpdu_verify(): src_ip=XX.XX.XX.XX failed.
 - flow-fanout[2177]: ftpdu_verify(): src_ip=XX.XX.XX.XX failed.

Currently I maintain a small patch to flow tools at my site to silence the 
ftpdu_seq_check() message, which freaks out if you have multiple flow sources 
feeding into a single capture.

Currently we just hard compile it out, but if I clean this up to make it an cmd 
line option, would you integrate it? We'd much rather stop hanging onto the 
local patch.  

Without it our logs get FLOODED with the messages due to the level of traffic 
and duplicate sequence numbers. 

         fterr_warnx(
           "ftpdu_seq_check(): src_ip=%s dst_ip=%s d_version=%d expecting=%lu received=%lu lost=%lu",
           fmt_src_ip, fmt_dst_ip, (int)ftpdu.ftv.d_version,
           (u_long)ftch_recexpp->ftseq.seq_exp,
           (u_long)ftch_recexpp->ftseq.seq_rcv,
           (u_long)ftch_recexpp->ftseq.seq_lost);


Alternatively, can you suggest any alternative means with flow-fanout to get 
rid of the warnings? (If it really is an issue, I'd rather fix it properly if 
possible.)

 Date: Thu, 20 Sep 2007 10:32:12 -0300
From: Fernando Garcia <[email protected]>
To: [email protected]
Subject: [Flow-tools] cflow-1.053 compile problem for flow-tools 0.68.1
X-Spam-Level:

Hello all    ,

Sorry if this is not the corret list, but in think it's strongly related...

Have anyone tried (and managed) compile Cflow-1.053 with flow-tools-0.68.1 ?

As recommended on INSTALL, Cflow must be compiled from dir contrib on
flow-tools dir. It looks for libft.a on ../../lib (considering it is in
contrib dir) to figure out it has to be compiled for flow-tools.

I figured out libft.a changed to libft.la on flow-tools-0.68.1.
Changelog has this comment:
"Compiles libft with -fPIC to work ok with libcflow-perl"

Dow anyone know any fix for this ? As cflow doens't find libft.a it
doesn't figure out it should be compiled for flow-tool.

I tried a little tick, changind Makefile.PL to look for libft.la. At a
first glance, it did work but when I run flowscan I got a weird error:
(probably due this "smooth" change).

-------- flowscan error --------------
Wanted function created
/usr/bin/perl: symbol lookup error:
/usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Cflow/Cflow.so:
undefined symbol: fterr_setid
---------------------

I'm using 64bit arch, Suse 10.1.

Trying to use flow-tools-0.68 (with patchs, due 64bit problem) Cflow
doesn't compile.

Regards,

Fernando

Please add a new output format for the flow-print emulating output
flow-extract.

What steps will reproduce the problem?
1. run flow-stat on flow capture files that all hit one bucket in the summary.  
For example, all packets are size 128.


What is the expected output? What do you see instead?
Should see 100% under 128 in IP packet size distribution.  Instead, .000 is 
displayed.

What version of the product are you using? On what operating system?
flow-tools-0.68.5.1, linux

Please provide any additional information below.
###the following has 12 packets, 10 with 106 bytes and 2 with 234 octets and 
flow-stat -f0 correctly shows 'IP packet size distribution" percentage's.
[jwacase@nickel flow-tools]$ flow-print < ft-v05.2012-03-07.121228-0700  
srcIP            dstIP            prot  srcPort  dstPort  octets      packets
10.156.1.2       10.156.8.202     6     42499    307      234         1         
10.156.1.2       10.156.8.202     6     273      42528    106         1         
10.156.1.2       10.156.8.202     6     546      547      106         1         
10.156.1.2       10.156.8.202     6     23879    54468    106         1         
10.156.1.2       10.156.8.202     6     34133    48553    106         1         
10.156.1.2       10.156.8.202     6     613      614      234         1         
10.156.1.2       10.156.8.202     6     35218    27234    106         1         
10.156.1.2       10.156.8.202     6     26011    63973    106         1         
10.156.1.2       10.156.8.202     6     42937    21264    106         1         
10.156.1.2       10.156.8.202     6     17609    13617    106         1         
10.156.1.2       10.156.8.202     6     62701    43400    106         1         
10.156.1.2       10.156.8.202     6     5628     23491    106         1    
jwacase@nickel flow-tools]$ flow-stat < ft-v05.2012-03-07.121228-0700 | grep -A 
2 "IP packet size distribution"
IP packet size distribution:
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .000 .000 .833 .000 .000 .000 .167 .000 .000 .000 .000 .000 .000 .000 

### the following has all flows as one size. and flow-stat -f0 is all 000's.. 
assume it is truncating to 3 decimal digits and losing the 1.
[jwacase@nickel flow-tools]$ flow-print < ft-v05.2012-03-07.121727-0700srcIP    
        dstIP            prot  srcPort  dstPort  octets      packets
10.156.1.2       10.156.8.202     6     273      42528    106         1         
10.156.1.2       10.156.8.202     6     546      547      106         1         
10.156.1.2       10.156.8.202     6     23879    54468    106         1         
10.156.1.2       10.156.8.202     6     34133    48553    106         1         
10.156.1.2       10.156.8.202     6     35218    27234    106         1         
10.156.1.2       10.156.8.202     6     26011    63973    106         1         
10.156.1.2       10.156.8.202     6     42937    21264    106         1         
10.156.1.2       10.156.8.202     6     17609    13617    106         1         
10.156.1.2       10.156.8.202     6     62701    43400    106         1         
10.156.1.2       10.156.8.202     6     5628     23491    106         1         
10.156.1.2       10.156.8.202     6     2814     35536    106         1         
[jwacase@nickel flow-tools]$ flow-stat < ft-v05.2012-03-07.121727-0700 | grep 
-A 2 "IP packet size distribution"
IP packet size distribution:
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 

### modifying ( a poor hack ) function print_3float lib/support.c to 
void print_3float(float f)
{
  printf("%#4.2f " , f);

/*  char s[10], *c;
  sprintf(s, "%-8.4f", f);
  sprintf(s, "%#0-5.3", f);
  c = s + 1;
  printf("%s ", f);
*/
} /* print_3float */

# gives the following, which alters the output to be d.dd versus .ddd, and thus 
shows the 100% case
[jwacase@fsa flow-tools-0.68.5.1]$ ./src/flow-stat < 
ft-v05.2012-03-07.121727-0700 | grep -A 2 "IP packet size distribution"
IP packet size distribution:
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

Command:
svn checkout http://flow-tools.googlecode.com/svn/trunk/ flow-tools-read-only

Get empty revision 22 :(

What steps will reproduce the problem?
No special steps: flow-tools data in my case is wrong all the time.

What version of the product are you using? On what operating system?
OS: 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1 08:49:13 UTC 2009
flow-tools: 0.68.4.1

I have two different servers that collect netflow data coming from the same
Cisco 7507 router. First server runs on old RH linux with flow-tools 0.66.
Second one has got FreeBSD plus flow-tools 0.68, which I replaced with the
latest flow-tools-ng version.

The problem is that under FreeBSD flow-tools report different amount of
traffic per IP which is much more big than reported on another server under
Linux. I googled this but found no similar cases so it seems like I'm the
only one who faced this trouble. 

I performed some test sending fixed number of packets to check what server
lies. And it is definetely about the new one under FreeBSD. Sometimes it
reports proper amount of traffic per IP-address, but ususally it reports
more than what was really sent. It could be just "more" or exactly twice
more etc. Practically saying, for now I can't rely on server's outcome and
I'm very confused about that as I completely failed to understand what is
the bug about.

Will appreciate any support.

What steps will reproduce the problem?
1. run flow-cat * | flow-report -v TYPE=ip-source-address-destination-count
2. Note the fields at the top:
# fields:               +key,+flows,+octets,+packets,+duration,+other
The field ip-destination-address-count (+key1) is missing.

This means that you cannot sort by the column you're trying to report on. 
Every other flow-report except ip-destination-address-source-count lists
this type of field as a key1 or key2.

I'm running 0.68.4 on FreeBSD 8-current.

What is the expected output? What do you see instead?

Fields "capture start" and "capture end" show date and time, but without
any timezone.  This makes it hard to use their output for other purposes.

What version of the product are you using? On what operating system?
0.68.2-rc2, NetBSD 3.1.

Please provide any additional information below.

patch attached.

1. flow-export -f1
2.
3.

What is the expected output? What do you see instead?
Expected output is a valid libpcap file it would appear both the tcp dump
versions minor and major are out dated as well as the magic number.

What version of the product are you using? On what operating system?
Latest stable version, on opensuse 10.3

Please provide any additional information below.
If more infomation is required please let me know.

thanks 
n keep up the amazing work.

[deleted issue]

What steps will reproduce the problem?
1. add -Werror=format-security to CFLAGS
2. build
3. watch it break:

DEBUG: fterr.c: In function 'fterr_info':
DEBUG: fterr.c:115:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
DEBUG:      syslog(LOG_INFO, buf);
DEBUG:      ^
DEBUG: fterr.c: In function 'fterr_err':
DEBUG: fterr.c:137:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
DEBUG:      syslog(LOG_INFO, buf2);
DEBUG:      ^
DEBUG: fterr.c: In function 'fterr_errx':
DEBUG: fterr.c:162:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
DEBUG:      syslog(LOG_INFO, buf);
DEBUG:      ^
DEBUG: fterr.c: In function 'fterr_warnx':
DEBUG: fterr.c:186:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
DEBUG:      syslog(LOG_INFO, buf);
DEBUG:      ^
DEBUG: fterr.c: In function 'fterr_warn':
DEBUG: fterr.c:208:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
DEBUG:      syslog(LOG_INFO, buf2);
DEBUG:      ^
DEBUG: cc1: some warnings being treated as errors


What is the expected output? What do you see instead?

Should just build.

What version of the product are you using? On what operating system?

0.68.5 on Fedora/rawhide

Please provide any additional information below.

Fedora is using -Werror=format-security in CFLAGS and flow-tools fails to 
build. Attached patch fixes it.

Are there any plans to support Internet Protocol Flow Information Export 
(IPFIX) ?  I'm hoping for IPv6 capabilities, so I don't have to find something 
different to use on my collectors.  Thanks.  

On large netflow flows (e.g. >800Mbit/sec) we constantly see following in logs:
Jan  3 12:12:00 radius-minsk2 flow-capture[98939]: STAT: now=1325581920 
startup=1324649629 src_ip=172.16.2.23 dst_ip=172.16.2.50 d_ver=5 pkts=77674720 
flows=2330241600 lost=22560 reset=3 filter_drops=0

In the same time udp dgrams dropped due to no socjet and due to full socket 
constanly increases: 

[gawriloff@radius-minsk2 /usr/home/gawriloff]$ netstat -s -p udp
udp:
        1378886026 datagrams received
        0 with incomplete header
        0 with bad data length field
        0 with bad checksum
        20888 with no checksum
        71766750 dropped due to no socket
        65910 broadcast/multicast datagrams undelivered
        43841072 dropped due to full socket buffers

Recv-Q on flow-capture is always non-zero:

[gawriloff@radius-minsk2 /usr/home/gawriloff]$ sudo netstat -na | grep udp4  
866304      0 *.2074                 *.*

[gawriloff@radius-minsk2 /usr/home/gawriloff]$ ps ugaxww | grep 2074
root       98945 96.0  0.0 12428  1868  ??  Rs   23Dec11 6227:38.04 
/usr/local/bin/flow-capture -w /var/netflow/flows/rtr10 -n 1439 -b big -z 9 -p 
/var/run/flow-capture.pid -N 0 -V 5 -S 1 0/0/2074

So I propose to increase  FT_SO_RCV_BUFSIZE from 4Mb to 8 in ftlib.h or better 
make it configurable through addition parameter.
For example: 
-sock 8Mb

NetFlow v9 support needed for IPv6 netflow handling.

flow-send Does not work on freebsd 7.0-STABLE
flow-tools-0.68_6 
example:
# flow-gen -V5 | flow-send -d9 127.0.0.1/127.0.0.1/9990
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: send(): Invalid argument
flow-send: processed 1000 flows
  sys:   seconds=0.002 flows/second=389863.547758
  wall:  seconds=0.002 flows/second=435540.069686

Can you, please, add some flow-tools documentation to the wiki? Manual
pages would suffice as a starting point.

Thanks!

What steps will reproduce the problem?
1. Enable flow on a large production router having more than 10 Links with 50 - 
100MBps terminated for remote location.
2. You would get flow files around 15 - 20 MB per minute.
3. CPU utilization is high when we start the flow-capture.

What is the expected output? What do you see instead?
I need to know how much flow rate was supported by flow-tools, and what is the 
recommended server hardware platform to capture flow for nearly 50 routers on a 
single server.

What version of the product are you using? On what operating system?
I am using flow-tools-0.68.5.1-1.el5 on Redhat enterprise linux 5 64 bit

Please provide any additional information below.
At present i am collecting flow data for one high utilization router with 10 
Links on it, for this alone my server's load average is going to 3 - 5, i would 
like to added more than 50 routers are the same server, can any one help me to 
fine tune / suggest the hardware to handle the load..

My Server configuration : 
CPU - 16 x 3.00GHz 
MEMORY - 16 GB
HDD - 440 GB In RAID5 Array

Thanks in Advance,
Ram

What steps will reproduce the problem?
1. flow-export IP in VARCHAR (mysql).
2.
3.

What is the expected output? What do you see instead?
Please output IP in INT (mysql) 

What version of the product are you using? On what operating system?
Freebsd 9.2

Please provide any additional information below.
Please. Write patch add option to flow-export so IP addresses will be output in
longint format rather than dotted quad (saves gobs of space in database).