ratop
Carter Bullard
carter at qosient.com
Mon Oct 22 22:47:30 EDT 2007
Can you share the binary for this, so I can see if there is a problem?
Carter
On Oct 22, 2007, at 8:22 PM, CS Lee wrote:
> Hi Carter,
>
> Here's the result,
>
> ra -L0 -nr ~/i-Pcaps/loadbalance.arg -s +1smac +2dmac
> StartTime SrcMac DstMac Flgs
> Proto SrcAddr Sport Dir DstAddr Dport
> SrcPkts DstPkts SrcBytes DstBytes State
> 19:33:06.063023 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.36024 ->
> 216.67.244.22.80 3 3 629 198 RST
> 19:33:27.653232 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.45640 ->
> 216.67.244.22.80 2 2 140 138 RST
> 19:33:57.899913 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2540 ->
> 216.67.244.22.80 2 1 108 60
> RST
> 19:33:58.907789 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2541 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:33:59.915817 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2542 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:34:00.923744 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2543 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:34:01.931729 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2544 ->
> 216.67.244.22.80 2 1 108 60
> RST
> 19:34:02.939714 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
> tcp 10.0.0.46.2545 ->
> 216.67.244.22.80 2 1 108 60 RST
> 12:03:14.936864
> man 0 0 16 1
> 28 9 2113 867416 STP
>
> 10.0.0.46 is the source in the data and only maps to one mac
> address which is 0:1b:77:5b:f4:3f.
>
> On 10/22/07, Carter Bullard < carter at qosient.com> wrote:
> Hey CS Lee,
> Well, this is right, but may not be exactly what you are expecting.
> We're going to build the radark() script up so that it does a lot
> more than just find some scanners in the big pile of flow records,
> so some of these early calls are really over designed for the simple
> first set of operations.
>
> With the calls to racluster(), we're keeping the Mac addresss <->
> IP address pairings, so we later can decide is this scan coming
> from the outside or the inside (just because its got an external
> IP address as a source address doesn't mean the packet
> originated from the outside).
>
> So based on what you've sent (and assuming no bugs) it looks
> like you've got some flows where 10.0.0.46 is coming
> from or to one ethernet address, and other flows where its
> mapped to another ethernet address. This can happen if
> there are two ways into a LAN.
>
> Run this against your original data:
>
> ra -nnr loadbalance.arg -s +1smac +2dmac | fgrep 10.0.0.46
>
> This should show us what ethernet addresses 10.0.0.46 is using.
> (you use the filter "- ip" to show your primitive data, but you don't
> use that filter in any of your racluster() commands, so you may
> be using arp flows in this run. maybe should add the "- ip" filter
> to the first racluster() call).
>
> The purpose of the third call to racluster(), is to generate a list of
> local IP addresses that are actively responding to external
> addresses, and 10.0.46 is indeed one of those addresses.
> If the address comes up twice, well that is not an issue for the
> program
> that will use it, rafilteraddr().
>
> Is this helping?
> Keep those questions coming!!!!
>
> Carter
>
>
> On Oct 22, 2007, at 2:24 AM, CS Lee wrote:
>
>> Hi Carter,
>>
>> First of all, congratulations for the argus 3.0 release, and I'm
>> looking forward for the client suite to reach that state.
>>
>> For ratop question, yes, it is over 1000 records per second.
>>
>> The explanation of radark is brilliant. And I have question
>> regarding it, I tried the command in the radark -
>>
>> Here's my data -
>>
>> ra -nnr loadbalance.arg - ip
>> 19:33:06.063023 e 6 10.0.0.46.36024 -
>> > 216.67.244.22.80 3 3
>> 629 198 RST
>> 19:33: 27.653232 e 6 10.0.0.46.45640 -
>> > 216.67.244.22.80 2 2
>> 140 138 RST
>> 19:33:57.899913 e 6 10.0.0.46.2540 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>> 19:33:58.907789 e 6 10.0.0.46.2541 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>> 19:33:59.915817 e 6 10.0.0.46.2542 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>> 19:34:00.923744 e 6 10.0.0.46.2543 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>> 19:34:01.931729 e 6 10.0.0.46.2544 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>> 19:34:02.939714 e 6 10.0.0.46.2545 -
>> > 216.67.244.22.80 2 1
>> 108 60 RST
>>
>> Then I tried -
>>
>> racluster -M norep -r loadbalance.arg -w loadbalance.racluster
>>
>> racluster -M norep rmon -m smac saddr daddr -r
>> loadbalance.racluster - appbytes gt 0
>> 19:33:06.063023 e ip 10.0.0.46 <-
>> > 216.67.244.22 3 3
>> 629 198 CON 19:33: 06.063023 e ip
>> 216.67.244.22 <-> 10.0.0.46
>> 3 3 198 629 CON
>>
>> I'm pretty clear until this part. 10.0.0.0/24 is the local net.
>>
>> The first call to racluster() generates the list of src and dst IP
>> addresses for flows that had some form of user data exchanged,
>> creating two entries for each set of src/dst IP pairs (using the -
>> M rmon we remove the src and dst semanitcs by creating entries (A -
>> > B and B -> A).
>>
>> But when I do -
>>
>> racluster -M norep rmon -m smac saddr daddr -r
>> loadbalance.racluster -w - - appbytes gt 0 | racluster -L0 -m smac
>> saddr -s +smac - src net 10.0.0.0/24 and not dst net 10.0.0.0/24
>> and src pkts gt 0
>> StartTime Flgs Proto SrcAddr Sport
>> Dir DstAddr Dport SrcPkts DstPkts SrcBytes
>> DstBytes State SrcMac
>> 19:33:06.063023 e ip 10.0.0.46 <-
>> > 0.0.0.0 3 3
>> 629 198 CON 0:1b:77:5b:f4:3f
>> 19:33:06.063023 e ip 10.0.0.46 <-
>> > 0.0.0.0 3 3
>> 198 629 CON 0:50:e8:2:3d:ca
>>
>> For me it doesn't look right especially the second record. I'm not
>> clear about the purpose of second parsing.
>>
>> Thanks.
>>
>>
>>
>> On 10/7/07, Carter Bullard <carter at qosient.com> wrote:
>> Hey CS Lee,
>> No, unless your processing 1000's of records per second.
>> Use ^G to display the processing stats at the bottom of the
>> screen. How records per second are you processing?
>>
>> Carter
>>
>> On Oct 6, 2007, at 1:08 AM, CS Lee wrote:
>>
>>> Hi all,
>>>
>>> I'm running argus dev on Ubuntu 7.04, and using ratop to monitor
>>> the traffic in realtime. Is it normal that ratop utilizes lots of
>>> resources as I have this -
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 14256 root 25 0 25572 19m 1164 R 98 0.9 1273:40 ratop
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> CS Lee<geekooL[at]gmail.com>
>>>
>>> http://geek00l.blogspot.com
>>
>>
>>
>>
>> --
>> Best Regards,
>>
>> CS Lee<geekooL[at]gmail.com>
>>
>> http://geek00l.blogspot.com
>
>
>
>
> --
> Best Regards,
>
> CS Lee<geekooL[at]gmail.com>
>
> http://geek00l.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20071022/69c1a6e7/attachment.html>
More information about the argus
mailing list