argus bivio bug when writing files?

[Carter Bullard]

Gentle people,
This problem, where many argi running on a single Bivio box, configured
to write their output to a file would generate unpredictable results, wasn't
a bug, but a mis-configuration.

Bivio is a multiprocessor box that provides coarse grain parallelism for
packet capture applications.  Bivio routes captured packets to a set of
processors, each running its own copy of of the packet analytic, in this
case its argus.  Each argi generates flow records for the subset of traffic
that it gets.  By combining the output of all the argi, you will get the complete
set of flow records for the high performance link that is being monitored.

This is also the basic strategy when running argus on Tilera, a 32, 64,
and now 100 core general purpose processor chip.

The problem was, in this case, that all these independent argi were
configured identically, to write their output to the same file.   Well, this
isn't a good thing to do, regardless of the application.  Argus doesn't do any
file locking on its output file, so this is not going to be a good thing to do.
Things should go maybe alright at first, but when the file is renamed,
each argi can take on the task of closing, and recreating the file, which
generates all kinds of race conditions and potential problems.  Some of the
argi will think the file hasn't changed, and continue to write into the old
file descriptor, etc….

The preferred strategy is for you to run a radium on a core in the Bivio
or Tilera, that collects the records from the various argi, and then the
single radium can provide access to the combined stream of argus data.

Depending on the architecture, and the nature of how packets are
routed to the individual processors, the combined output may need to be
processed by racluster() to combine any potential flow fragments, create
bi-directional flows from uni-directional flows, and to do the P1/P2 flow
processing, such as matching ICMP packet with causal flow records.

Processing the combined output using rasplit() or rabins(), which can also
run on the Bivio, or in the case of Tilera, on the host processor, allows you
to control the the load and maintain the performance.

If you're having problems running argus on Bivio or Tilera, don't hesitate
to email / call / whatever.


Carter


On Jul 26, 2012, at 12:58 PM, Carter Bullard wrote:

> Gentle people,
> We've got a bug report on Bivio, when argus is configured to write to a file.
> When the file is moved, argus doesn't appear to do the right thing, sometimes
> not recreating the file, or seeing zero length files.
> 
> I have found a condition where argus may close and open the output file
> too often, but code inspection isn't revealing much.  I have a patch for the
> errant closing and opening condition, and that will be in the next release.
> 
> Anyone else seeing problems when argus is configured to write to files, 
> and you move the files periodically?
> 
> Hope all is most excellent,
> 
> Carter
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120802/2b3ef2f0/attachment.html>
-------------- 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/20120802/2b3ef2f0/attachment.bin>