color support

Dave Edelman dedelman at iname.com
Thu Oct 25 21:33:56 EDT 2012


Thinking about ways that I would use the feature, I think that your sample
of ISO two letter codes and an associated color makes good sense. I'm not
sure if there isn't a need to define a transparent color for those instances
where you want to suppress the display regardless of the background. 

 

I like the idea of aggregation but I think that there are cases where
politics trumps geography. EMEA for Europe, Middle East, and Africa is
commonly used, CEEMEA for Central and Eastern Europe, Middle East, and
Africa has had its 15 minutes of fame. The only place that you are going to
find Mexico in North America is in Wikipedia. 

 

Is it easier to build the aggregation or to deaggregate the exceptions? 

 

On a separate note, I do quite a bit of work with NetFlow V5 and there are
data elements that are in the flow records that don't really fit neatly in
the DSRs that you populate. I'd like to try populating some of them in a
Label DSR. Is this a very bad idea? The input and output  interface
information and the next hop information is sometimes very useful.

 

--Dave

 

From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Thursday, October 25, 2012 6:11 PM
To: Dave Edelman
Cc: elof2 at sentor.se; 'Argus'
Subject: Re: [ARGUS] color support

 

* PGP - S/MIME Signed by an unverified key: 10/25/2012 at 6:11:03 PM

Hey Dave,

Yes country code coloring is a good thing.

 

So how should we configure it ?   We use InterNIC files for country codes.

But I don't recommend that we add color to those entries, and since most

are getting country codes from GeoIP, we should add color as a separate

configuration?

 

CN,TW,RU         RED

US,EU,CA          BLUE

 

I have continent / country code listings now, so we can also support
continent

coloring, with specific country coloring as exceptions?

 

Carter

 

 

On Oct 25, 2012, at 5:52 PM, "Dave Edelman" <dedelman at iname.com> wrote:





 

ArgusColorGeoLocation() would be very nice. The ability to quickly identify
flows where source|destination|both have addresses allocated to countries
that have strict limits on where their traffic may go or with whom I may not
communicate has more practical application than I would have thought three
days ago.

 

--Dave

 

From:  <mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu>
argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu [mailto:argus-
<mailto:info-bounces+dedelman=iname.com at lists.andrew.cmu.edu>
info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On Behalf Of Carter
Bullard
Sent: Thursday, October 25, 2012 12:32 PM
To:  <mailto:elof2 at sentor.se> elof2 at sentor.se
Cc: Argus
Subject: Re: [ARGUS] color support

 

> Old - S/MIME Signed by an unverified key: 10/25/2012 at 12:31:31 PM

Hey Elof,

More on the topic of color.

So I've got some of the framework for color configuration going, here is
what I'm doing in a racolor.conf file.

Need some suggestions / criticisms before I finalize an implementation.

 

Currently I have an array of 256 color methods to apply to each line before
we draw.

We run each method that is configured, then we draw the line.  Haven't
figured out, yet, what

a decent configuration method is for specifying what methods should be the
array.  I suspect

that once we have a bunch of methods, we'll configure a "list the method"
style of configuration.

 

Right now, I have two methods, ArgusColorAvailability(), and
ArgusColorAddresses()

that I'm using to test.  These are hardcoded as method 1, and 2 in the
array, respectively.

 

If you use " - A " on the command line, the availability testing kicks in
and we do a good

test on the argus record to determine if a flow has failed.  If so we'll
color it ORANGE (hard coded right now).

 

Next we do the ArgusColorAddresses() method, and its what I mentioned in
earlier email, also hard coded.

 

This is working very well.  Need more methods, and I need method specific
configurations, so still a lot of

work to do.

 

The next method will be the ArgusColorFlowField() routine that I described
below.  Here is the sample

configuration I've worked out:

 

 

# Ra client flow based color configuration support

#

# Carter Bullard

# QoSient, LLC

#

#   This configuration is a racolor(1) flow model configuration file.

#

#   The concept is to bind a traditional ra* filter with an

#   color map for fields in the argus record.  Records are tested

#   against the filter specifications in "fall down" order, when they match,

#   the color model is applied to output.

#

#   The use of the ' cont ' keyword will allow you to specify a

#   painters algorithm for coloring individual flow records, using

#   display programs like ratop().

#

#   Available colors

#

#   The color models available are extensible, but at a minimum,

#   assume you have 16 basic colors plus white and black, to choose

#   from.  These colors are referred as:

#           WHITE, BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, ORANGE,
VIOLET,

#           BASE03, BASE02, BASE01, BASE00, BASE0, BASE1, BASE2, BASE3 

#

#   Traditional graphics color terms usch as BACKGROUND and FOREGROUND are
also

#   available. 

 

#   Available Attributes

#   

#   These tools also support assigning terminal attributes as well, these
include:

#

#    STANDOUT              Best highlighting mode of the terminal

#    UNDERLINE             Underlining

#    REVERSE               Reverse video

#    BLINK                 Blinking

#    DIM                   Half bright

#    BOLD                  Extra bright or bold

#

#   How these colors and attributes interact to generate display effects

#   is implementation specific, so you'll have to play to get exactly what

#   you want.

#

#   Because the color map is extensible, anything is really possible.

#   If the underlying display devices can handle more graphics support,

#   you should be able to pass Hexidecimal color values, using the #XXXXXX

#   format.

#

#   The color map assignement syntax is:

#      field specification

#         field[,field,...]=color[:attribute][;field specifciation[;....]]

#      

#   All printable fields can be used.  The Keyword 'all' is used to specify

#   the complete output line.

#

#      srcid=BLUE

#      saddr,daddr=BLUE;smac,dmac=CYAN

#      all=RED:BLINK

#

#   Here is a sample configuration file

#   

#

filter="src co CN'           saddr=RED             cont

label="ALERT"                all-RED

filter="load gt 1M"          sload,dload=VIOLET   

filter="load gt 10M"         sload,dload=RED      

 

Hopefully this gets the ideas going.

 

So if I put ArgusColorFlowField() as #3 in the array, it gets the colormap
from the other

two methods, and then paints based these rules.  With the " cont " keyword,
regardless

of a hit, we'll keep going down the list.

 

Can we use this?

Hope all is most excellent,

 

Carter

 

On Oct 23, 2012, at 6:27 AM,  <mailto:elof2 at sentor.se> elof2 at sentor.se
wrote:







On Tue, 23 Oct 2012, Carter Bullard wrote:




Hey Elof,
There are many reasons to color a record or a part of a record, and I'm
thinking of having a list of methods that result in a painters algorithm, to
generate the final result.
Somewhere in that list of color methods is address coloring.  So if you want
the whole record RED, because of some fault condition, but you want the
addresses colored because of locality, you would specify the fault method
first, the address method second.


Rules applied in order sounds very logical and sound.





In the implementation so far, we know what each column is, and the coloring
can be targeted at any field, group of fields or the whole record.  So if
you have a minimum byte count condition, as an example, you should have a
way of specifying that conditional against the field and then indicate what
fileds get what color.


Nice.





I'm working with our standard filters, like we use for aggregation, with a
field=color directive.  Does that sound useful ?


Yes, very!

/Elof




 

* Carter Bullard < <mailto:carter at qosient.com> carter at qosient.com>
* Issuer: "VeriSign - Unverified

 

 

* Carter Bullard <carter at qosient.com>
* Issuer: "VeriSign - Unverified

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121025/2eb25b56/attachment.html>


More information about the argus mailing list