rafilteraddr issue

[Carter Bullard]

Hey Phillip,
The interesting thing is that the label matching is a regular
expression matching, so you can do really cool things, if you've
put some thought into your label scheme.

We call this "semantic enhancement" and it can be very useful.
The labels support a very specific metadata format, and all the tools
know how to aggregate labels.

racluster() can use these labels as a basis for aggregation decisions.
Check out how the ./support/Config/racluster.conf example configuration.
It has a flow matching rule like this:
  filter="Class-Video"  model=".....

So imagine a pipeline of flow records, where radium() labels flow records,
and one of its rules is to mark traffic as "Class-Video".  This type of rule,
while simple, does work for many video transports:

   filter="rtp and src load gt 1800000 and lt 2200000"  label="Class-Video:"

So, you get traffic with a "Class-Video" label in the argus flow stream.

One challenge has been to keep traffic of interest at a high level of detail
but aggregate all other traffic to a low level of detail.  ralabel() allows
you to label traffic of interest, and then racluster() can use the labels to
decide to not aggregate a record.

So the ./support/Config/racluster.conf file, provides different aggregation
schemes based either on flow matches, or labels, and can give you some
good results.

Definitely give it a try.

Carter

On Feb 5, 2010, at 3:12 PM, Phillip Deneault wrote:

> On 2/5/2010 2:03 PM, Carter Bullard wrote:
>> What do you think?
> 
> I think it might be a better solution than using rafilteraddr for what I
> ultimately am trying to do. :-)
> 
> I guess I picked rafilteraddr because I was pondering the differences in
> speed that would come from a large set of facts to try to match against,
> per your comment here:
> http://thread.gmane.org/gmane.network.argus/5341/focus=5344
> 
> but since I could label flows as they came in, then the processing load
> for the label marking would be distributed and the processing load for
> the data querying would be limited to just a few columns in the ra
> files.  Do you agree?
> 
> Thanks!
> Phil
> 
> On 2/5/2010 2:03 PM, Carter Bullard wrote:
>> Hey Phillip,
>> Sorry I haven't responded!!!  So here is where I am on this:
>> 
>> Its not a bug, by default rafilteraddr() matches only exact matches,
>> and CIDR matches are, of course, not exact matches.
>> 
>> But this, of course, is not what we want.  I believe that I have a solution,
>> but I need to test it out a bit.
>> 
>> As a work around, I might suggest that you use ralabel() to do what you
>> want.  As an example, using the sample ralabel.conf and iana-address-file
>> from the ./support/Config directory in the client distribution, you can take your
>> address list, and have it insert the label "match" into the flow stream, and
>> then use ra() to find flows that have the label "match" in them:
>> 
>>   ralabel -f ralabel.conf -r /data/argusinput -w - | ra -M label=match
>> 
>> The ralabel.conf file contains:
>>   RALABEL_IANA_ADDRESS=yes
>>   RALABEL_IANA_ADDRESS_FILE="filtertest.txt"
>> 
>> and your filtertest.txt file contains:
>> 
>>   192.168.1.0/24   match
>> 
>> You can make this much more complicated, and so much more than just
>> filtering with these schemes.   Hopefully it will provide you with a workaround
>> until I get the fix in. I should have a solution for rafilteraddr() by the weekend?
>> 
>> What do you think?
>> 
>> Carter
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100206/0606748e/attachment.bin>