New RA_LOCAL support in rarc

[Carter Bullard]

Gentle people,
With argus-clients-3.0.7.4 we've introduced some new features, motivated by the
new color support of ratop().  In particular, we've added the ability to specify
what is LOCAL, based on L2 and L3 addresses, and to use that assignment
in reports, and display technology.  I'd like to discuss how we can use these
LOCAL assignments, to make things better, good and cool.

We're very early in this type of support, so anything is fair game for defining
the features, and how to use them, so don't be shy !!!

Assigning addresses to LOCAL currently uses the same strategies as
ralabel().  You assign the RA_LOCAL variable the contents of a file,
which contains a list of CIDR addresses.  Anything specified is considered
LOCAL, and the list can be as detailed as necessary, or simply be a
single CIDR range, its up to you.  While the configuration looks like your
assigning the RA_LOCAL variable, its not quite that yet.  Based on our
discussion, how the RA_LOCAL variable is used is up to us.

One of the uses of this feature, is to provide flexibility on how to display
flow data.  Some reports would like the LOCAL addresses to always be
on the left.  This is particularly useful when you use highly aggregated
data, where the direction of each flow isn't an issue.

As an example, when you're generating matrix data for access control
validation, and performance or traffic engineering purposes, what order the
address pairs are displayed should be configurable, because there is
no notion of direction.   I'm working now to implement this simple feature.

I also see where one could use the RA_LOCAL definition as a variable, such
as $LOCAL.  Being able to use this as a filter element, should be powerful.
I believe that we can do that pretty easily, but discussion on how to
use it would be nice to guide the first implementation.

Implementing these types of features is slightly tricky.  What I'm realizing
now, is that the $LOCAL display directives, should not be direction
assignments, redefining the SRC and DST relationships, as that can
screw up filters and the like.

What that really means is that we have to implement the features, late
in the processing pipeline.  So, we end up applying these features as
we output data, not as we input them.

As Elof2 pointed out in earlier email, some of the configuration name choices
need to be fleshed out.   So, please send opinions, suggestions, attitude,
whatever, regarding the use of his new LOCAL feature…  and we'll get
this going for the 3.0.8 release in 2-3 months.

Looking forward to your input, Hope all is most excellent,

Carter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121214/9f7302fd/attachment.bin>