Racluster and the trans field

[Nick Diel]

Carter,

My data is "primitive" data.  It hasn't been through racluster (I just used
a large -S value with Argus).  So this code may still be in question.  Let
me show you the different output I get with that just that code change.

I have an argus file with flows from all the same host.

racount -r file.argus
racount   records     total_pkts     src_pkts       dst_pkts
total_bytes        src_bytes          dst_bytes
    sum   32          1012           529            483
269322             229185             40137

Original racluster
racluster -r file.argus -m sadddr -s trans
26

Modified racluster
racluster -r file.argus -m sadddr -s trans
31

Perhpas in the ArgusMergeRecord routine we need to check to see if count is
less than 1 and handle this case there?

Nick


On Sat, Aug 29, 2009 at 2:50 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Nick,
> I don't think this code is the source of your discrepancy.
>
> This part of the code is creating an AGR if there isn't one in the argus
> record.
> When there isn't an AGR, it means that there hasn't been any aggregation
> done, so this implies a "primitive" record.  The AGR holds statistics for a
> specific metric, and by default that metric is the duration of the argus
> record.
> You can specify a different metric by defining an ArgusAggregator object,
> and telling it what metric you want the ArgusMergeRecord routine to
> calculate.
>
> So we are setting the "agr->count = 0" only when we're doing the stats on
> the
> duration of the argus record, and the duration is equal to zero.   This
> seems
> ok to me.  And we need this correction.
>
> Well, anyway, if you have a data file that generates bad counts, send it my
> way
> and I'll fix.
>
> Carter
>
>
> On Aug 29, 2009, at 3:29 PM, Nick Diel wrote:
>
>  This is actually a continuation for a bug we discussed a little bit ago
>> and something CS Lee looked at too.
>>
>> When you use racluster the trans field did not always add up correctly (it
>> would be smaller than it should be).  Again I dug into the source code and
>> think I found the culprit.  We actually set the trans field to 0 in some
>> cases.  I am not entirely sure why we do this, but it does cause a couple of
>> problems.  Also what confuses this even more is we now always print a trans
>> field of 1 or greater (we actually test the trans field, if 0 or smaller we
>> just print 1).
>>
>> For the second part of the problem, we do use the value of the trans field
>> internally to test whether or not to some duration calucations and with the
>> current logic we do not compute duration on some flows I think we should.
>>
>> First here is the code in question (from diff):
>> --- origs/argus_client.c        2009-08-29 11:35:55.000000000 -0600
>> +++ common/argus_client.c       2009-08-29 11:42:58.000000000 -0600
>> @@ -4040,15 +4040,6 @@
>>                      agr->act.minval             = 10000000000.0;
>>                      agr->idle.minval            = 10000000000.0;
>>
>> -                     if (parser->ArgusAggregator != NULL) {
>> -                        value =
>> parser->ArgusAggregator->RaMetricFetchAlgorithm(retn);
>> -                        if (ArgusFetchDuration ==
>> parser->ArgusAggregator->RaMetricFetchAlgorithm) {
>> -                           if (value == 0)
>> -                              agr->count = 0;
>> -                        }
>> -                     } else
>> -                        if ((value = ArgusFetchDuration(retn)) == 0)
>> -                           agr->count = 0;
>>
>>                      if (agr->count > 0) {
>>                         agr->act.maxval             = value;
>>
>> I am not entirely sure what we are testing for so the question is do we
>> need this code, if so is it correct, and finally should we move the logic so
>> we are not ever setting the trans field to 0?
>>
>> Nick
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090829/d1f62b3d/attachment.html>