[netflow-tools] Softflowd and rrd running on the same machine

[Damien Miller]

Bogdan Ghita wrote:
> Hello everybody
> 
> I've installed a few days ago softflowd and rrd-associated tools
> (flow-capture/flowscan) on a monitoring machine connected to a local
> network. First, I'll start with the praise - it's a great software, I've
> been looking for a long time at netflow-related software, but couldn't
> find anything that would allow me to implement it via a monitoring
> machine. Everything seems to be working reasonably well at the moment,
> but I still have a couple of problems that I can't find the solution
> for:
> 
> - out-of-order packets. In order to get softflowd and rrd to work, I'm
> sending packets via the local interface of the machine. I thought this
> would work just fine but flow-capture reports continually 'lost'
> packets: 
> 
> Apr 29 11:27:18 linux flow-capture[23080]: ftpdu_seq_check():
> src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx d_version=5
> expecting=28199800 received=28199770 lost=4294967265
> Apr 29 11:27:18 linux flow-capture[23080]: ftpdu_seq_check():
> src_ip=xxx.xxx.xxx.xxx dst_ip=xxx.xxx.xxx.xxx d_version=5
> expecting=28199800 received=28199770 lost=4294967265

This might be a bug in the sequence number generation of softflowd, or a
bug in flow-capture - flow-capture is certainly printing negative
sequence number offsets incorrectly.

Can you capture some softflowd output packages with another netflow
capable tool to manually check the sequence numbers? E.g. tcpdump's
cnfp mode, flowd, etc.

> Is it possible (I've don very little in terms of socket programming, so
> the answer might be straightforward) to pipe softflowd straight into
> flow-capture, so that the communication will be (hopefully) smoother?

It is highly unlikely that the packets are acually getting dropped. It
is more likely a bug in one/both packages.

> - CPU usage - softflowd seems to behave very strange when changing the
> priority - with the default priority (0), it uses continuously about 80%
> of the processor (yes, it is a big network and, again, yes, it is a slow
> machine - P3-900MHz); when I renice it (via 'top') to lower priority
> (e.g. 10), the utilisation drops to about 20%, although the processor
> is, overall, only about 50% used. Is the collector dropping packets/flow
> during that time? Is the machine that slow?

It is difficult to tell whether or not you are dropping packets - it
depend a lot on what happens on the kernel side too. I'm not sure what
information on packet drops libpcap makes available, but the attached
patch adds printing of the statistics that it does provide to those
printable using "softflowctl statistics".

I'm not sure what a "dropped packet" in libpcap's parlance is - it may
be a drop because the client couldn't keep up, or a drop from a bpf
filter program. It should be obvious once you start playing with it
though :)

> - Reports - I am not sure whether this is a softflowd problem or an
> rrd-related problem. I've noticed a continuous udp flow running over the
> network, quite considerable in terms of bandwidth. However, when drawing
> the graphs, there is only an hourly spike, and nothing else. What could
> be causing this type of reporting?

That depends on how the data is being presented - if you are showing
flow records vs time, then a long UDP conversation may be represented by
only a single flow record. Retrospectively producing throughput vs time
representations of long-lived flow conversations is a little tricky and
requires some suppositions, as the flow record summarises away any
dynamics in the conversation.

-d
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: softflowd-pcap-stats.diff
Url: http://lists.mindrot.org/pipermail/netflow-tools/attachments/20050430/05f7807f/attachment.ksh