Huge argus files and racluster

[Marco]

Il 09 febbraio 2012 03:08, Peter Van Epp <vanepp at sfu.ca> ha scritto:
> <snip>
>>
>> The second one is more of a philosophical issue, and now I'm wondering
>> whether argus is really the tool I need for the task. Basically, since
>> I need to determine incoming/outgoing bandwidth usage, I'm using
>> "ragraph sbytes dbytes" to produce the graphics. If every flow is
>> initiated from the LAN being monitored (say, 192.168.44.0/24), then
>> "sbytes" effectively indicates the amount of physically outgoing data,
>> and "dbytes" effectively indicates the amount of physically incoming
>> data, so the resulting graph is an accurate representation of in/out
>> bandwidth usage over time. But if there are externally-initiated flows
>> (as in my case) along with internally-initiated ones, then "sbytes"
>> will aggregate a mixture of data leaving and entering the network,
>> depending on who initiated the flow being considered. The same happens
>> for "dbytes". What this means is that a "ragraph sbytes dbytes" isn't
>> really representing bandwidth usage in the two directions (the
>> aggregate value "bytes" is still correct, but doesn't give any detail
>> about what's outgoing and what's incoming).
>> So obviously this isn't argus' fault, but I'm wondering whether
>> there's a way to do what I'm looking for (with argus or another tool).
>> It's also possible that I'm missing something obvious.
>>
>> Thanks again for the quick replies and your patience.
>>
>
>        You aren't missing anything obvious :-) but argus is a good tool for
> monitoring bandwidth (I used it to do so for more than 10 years before I
> retired). There are a few tricks needed thats all. You have found the most
> important one, that argus is layer3 and source and destination (at least by
> default) don't bear any relation to physical in and out. However if you add
> the -m flag to your argus (to preserve MAC addresses in the argus records
> which are off by default) you can then use the RMON settings along with a
> source filter (because RMON reports every connection twice, once for source
> and once for dest) to tie src and dest to the needed layer2 direction.
> Basically (Carter can give you the incantations, I used perl scripts rather
> than the modern clients :-)) convert to RMON and filter on src (or dst if you
> choose but only one or the other not both) on your gateway's MAC address
> to convert src to out from your network (or in to your network) and then pass
> that data to the analysis clients that you want to use. Although I don't think
> you can use the clients to do this, the perl scripts read ra data and knowing
> what address blocks belong to our network swapped the src and destination
> records so that the resulting data was layer 2 corret. This may be useful
> (and possibly your only choice) if you had a large bridged domain (i.e. not a
> single or a couple of gateway MACs) in your data.
>
> Peter Van Epp

I had tried that indeed, but I thought that one could do it "on the
fly" (ie, just add "-M rmon" to the client, and add a filter on
src/dst/etc in the same command), while it turns out that you have to
explicitly write a new argus file from the -M rmon output, and then
run subsequent commands on that new file. It even looks like you don't
need the MAC information, at least in the few tests I've done so far.

Thanks!