Problems with racluster

Wed Sep 26 04:31:05 EDT 2012

Hi Carter,

I think in this case the aggregation you propose is correct, although I
would not have strong arguments to defend it or oppose it. Very curious
case.

However, the cause of the problem is a little more deep. Looking at the
pcap data, I only see SYN packets going from A.xxx to B.yyy and never the
opposite. The same is valid for SYN/ACKs, always from B.yyy to A.xxx. There
is a massive amount of duplicated packets in my trace. Every SYN packet in
this connection appears 4 times (original + 3 duplicates) and the same
SYN/ACK packet can appear up to 16(!!!) times. This probably makes the TCP
state machine to go crazy.

I am not sure why these happens, if this represents the actual behavior of
the network or if there was some problem with the measurement setup.
However, as the duplicates are several seconds apart, I would be reluctant
to believe they are the same packet crossing the measurement point twice
(the measurement represents a LAN environment).

I will upload the original pcap files, so that you can discover why the
direction is reversed in some flows.

Rafael Barbosa
http://www.ewi.utwente.nl/~barbosarr/

On Wed, Sep 26, 2012 at 12:44 AM, Carter Bullard <carter at qosient.com> wrote:

> Hey Rafael,
> OK, so I'm fixing this now, and there is a curious situation. You've got
> these flows:
>
>     A.xxx  ->  B.yyy  with indications of Syn, SynAck and Reset
>     B.yyy <?>  A.xxx  with SynAck and Reset
>     B.yyy  ->  A.xxx  with Syn, SynAck and Reset
>
> So, the correct output after aggregation is to have two records output
>     A.xxx  ->  B.yyy  with indications of Syn, SynAck and Reset
>     B.yyy  ->  A.xxx  with Syn, SynAck and Reset
>
> The curious thing is, do you think that argus  is making the correct
>  assignments ?
>
> Carter
>
> On Sep 25, 2012, at 5:56 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:
>
> Hi again,
>
> I still see some subnetwork aggregation. Most of it at roughly the same
> time, so hopefully they are caused by the same bug. Same config as before.
>
> The error appear when running:
> $> ~/workspace/argus-clients-3.0.7.2-patch/bin/racluster -r part1 part2 -f
> ~/config/racluster.conf
>
> I see another subnet aggregation later in the trace, but I am having
> problems replicating it in a small test. I will try again when I get some
> more free time.
>
> I uploaded parts.tar.gz containing part1 and part2 to the ftp.
>
> Rafael Barbosa
> http://www.ewi.utwente.nl/~barbosarr/
>
>
>
> On Wed, Sep 19, 2012 at 5:11 AM, Carter Bullard <carter at qosient.com>wrote:
>
>> Hey Rafael and Harika,
>> Use this racluster.c with your argus-clients-3.0.7.2, to see if it solves
>> that last direction problem you reported.
>> Thanks !!!!
>>
>> Carter
>>
>>
>>
>> On Sep 13, 2012, at 5:09 AM, Rafael Barbosa <rrbarbosa at gmail.com> wrote:
>>
>> Hi Carter,
>>
>> I still see some records aggregated by subnet (?!), with the same
>> racluster.conf.
>> I will upload 2 more files (preagg2.argus and preagg3.argus) where I see
>> the bug.
>>
>> Rafael Barbosa
>> http://www.ewi.utwente.nl/~barbosarr/
>>
>>
>>
>> On Wed, Sep 12, 2012 at 3:42 PM, Rafael Barbosa <rrbarbosa at gmail.com>wrote:
>>
>>> Hi Carter,
>>>
>>> The new version seems to have solved the issue. As a bonus, is also
>>> seems to have solved the direction bug when the SYN packet is missing I
>>> reported in another thread.
>>>
>>> I will start some larger tests and let you know if I run in other issues.
>>>
>>> Thanks!
>>> Rafael Barbosa
>>> http://www.ewi.utwente.nl/~barbosarr/
>>>
>>>
>>>
>>> On Wed, Sep 12, 2012 at 2:34 PM, Carter Bullard <carter at qosient.com>wrote:
>>>
>>>> Hey Rafael,
>>>> Try this version of argus-clients-3.0.7.2. Had to modify too many files
>>>> to send a simple patch.
>>>> Should do the trick.
>>>> Carter
>>>>
>>>>
>>>>
>>>> On Sep 12, 2012, at 5:19 AM, Rafael Barbosa <rrbarbosa at gmail.com>
>>>> wrote:
>>>>
>>>> Hi Carter,
>>>>
>>>> I am still having problems with the patch. My aggregation strategy is
>>>> the same:
>>>> $> cat racluster.conf
>>>> #Filter:every record, no record status output, record time out 5min
>>>> filter="" status=0 status=60 idle=300
>>>>
>>>> However I see some records aggregated by subnetwork(?!). If I run:
>>>> $> ~/workspace/argus-clients-3.0.7.1-patch2/bin/racluster -r
>>>> preagg.argus -f racluster.conf -s saddr,sport,dir,daddr,dport
>>>>
>>>> One of the lines read:
>>>> 172.31.0.0.*         ->         172.31.0.0.*
>>>>
>>>> I will upload preagg.argus to the ftp.
>>>>
>>>> Best regards,
>>>> Rafael Barbosa
>>>> http://www.ewi.utwente.nl/~barbosarr/
>>>>
>>>>
>>>>
>>>> On Mon, Sep 10, 2012 at 5:42 PM, Rafael Barbosa <rrbarbosa at gmail.com>wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> Ok. That makes sense to me.
>>>>>
>>>>> My goal was to have a TCP flow == 1 record and I assumed because of
>>>>> the SYN and FIN packets these records would not be aggregated. But I think
>>>>> the output of racluster is now sufficient for my purposes.
>>>>>
>>>>> Best regards,
>>>>> Rafael Barbosa
>>>>> http://www.ewi.utwente.nl/~barbosarr/
>>>>>
>>>>>
>>>>> On Mon, Sep 10, 2012 at 3:13 PM, Carter Bullard <carter at qosient.com>wrote:
>>>>>
>>>>>> Hey Rafael,
>>>>>> I believe that its now working as advertised.
>>>>>>
>>>>>> Your " f1 " is done at 15:09:30.971092 and " f2 "
>>>>>> starts at 15:11:52.493899,  which is
>>>>>> only 141.522 seconds of idle time.  So you're racluster.conf strategy
>>>>>> should only generate
>>>>>> 1 flow record.  If you want to see status records at shorter
>>>>>> intervals, but have the 300
>>>>>> second idle time, add something to your status timer value, like 60
>>>>>> or 120 seconds.
>>>>>>
>>>>>> Carter
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120926/75046c3d/attachment.html>