netflow record direction indicator

[Carter Bullard]

Hey Adriano,
Netflow records are unidirectional, that's one of the reasons they are such a
poor data source for flow analysis.  You have to aggregate netflow records to get
bi-directional flow records out of them.   racluster() will do that very well for files,
and rabins() can do that for streaming data.

Because netflow doesn't capture enough information to make a 
definitive determination on direction, the direction field may not change
when the two sides are merged together, all depends on the specific flow,
and the data can't be trusted so we'll almost always have a ' ? ' in the dir field.

The real problems are with fast connections, like DNS.  Netflow, much of the time,
will output the response flow record first, followed by the request flow record, and 
the time stamps will be the same time, because netflow doesnt have the time
resolution needed for these microsecond transactions.

racluster() will take the first flow record as reflecting the origination flow, and the
second as the responding flow, if the timestamps are equal.  So the resulting argus
data will present with the wrong direction, and zero duration.  We do indicate
in the record that the values were derived from Netflow ('N' in the flags field), so
we know that there can be issues with the data.

Sure does bite when you're trying to do real flow work.

Carter


On Nov 29, 2012, at 10:45 AM, Adriano wrote:

> 
> $ ra -S cisco://any:port
> 
> Should it show which flows are bidirectional, right ? Every line for
> TCP is with  "?>" and none with "<->".
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121129/c806c1c0/attachment.bin>