[netflow-tools] problems with pfflowd that don't happen with softflowd

[Michael W. Lucas]

On Sat, Apr 30, 2005 at 09:58:30PM +1000, Damien Miller wrote:
> Michael W. Lucas wrote:
> >Hi,
> >
> >I'm currently using softflowd on FreeBSD 5.4, trying to switch over to
> >pfflowd to get more timely exports of flows.  (It *seems* that
> >softflowd exports flows much later than when the traffic actually
> >stops, and it *appears* that pfflowd expires these flows more
> >quickly.)
> 
> That is possible: softflowd's timeouts are pretty conservative,
> especially for TCP - 30 minutes post-FIN. You can tune these on the
> commandline though :)

Ah, you learn something every day.

That 30 minutes can be important when you want to, say, grovel through
netflow data looking for port scans and worms and whatnot.  :-)

> When you run tcpdump, did you try the "-T cnfp" to get it to parse the
> NetFlow packets? What collector are you using?

I'm using flow-tools' flow-capture.

Under softflowd, -T cnfp on the collector shows:

08:08:01.118622 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs
08:08:01.118770 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 30 recs
08:08:01.118918 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs
08:08:01.118923 IP a.b.c.d.52011 > w.x.y.z.9318: NetFlow v5, 179.007 uptime, 1114862881.120821000, #0, 29 recs

with pfflowd, we see:

08:10:20.540514 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542900000, #0, 12 recs
08:10:20.540519 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542953000, #12, 12 recs
08:10:20.540662 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542971000, #24, 12 recs
08:10:20.540668 IP a.b.c.d.57523 > w.x.y.z.9318: NetFlow v5, 8.741 uptime, 1114863020.542987000, #36, 11 recs

The only difference I see is that with softflowd, the # doesn't
increment.

I'm willing to accept that there's something in flow-capture that's
choking on something with pfflowd.  Still, it seems that there will be
more people on this list using flow-capture than there will be on the
flow-capture list using pfflowd and softflowd.  :-)

I'm also using the same flow-capture binary to collect netflow from a
Cisco router, so I somehow think that there's some detail with pfflowd
that I just don't have right.

==ml

-- 
Michael W. Lucas	mwlucas at FreeBSD.org, mwlucas at BlackHelicopters.org
		http://www.BlackHelicopters.org/~mwlucas/
	       Latest book: Cisco Routers for the Desperate
	        http://www.CiscoRoutersForTheDesperate.com