default interfaces to monitor

[Carter Bullard]

Hey John,
I generated a pretty long response to your email, sorry.  If I didn't
answer your question, send some more mail, and I'll be more
direct.  The answer is yes you can, and use radium() to merge
the flows, but the topic of multiple interfaces is complicated,  that
is why the rest of my response is lengthy.  But quickly, to read
multiple interfaces at a time use multiple "-i int" options on
the command line or multiple "ARGUS_INTERFACE=" entries
in the argus.conf.  But  this may not be the best way, you may
already be doing the right thing with multiple argii.   Use radium()
on the same machine as the 2 argii to collect records from both
and to provide a single socket for others to get the merged data.

Don't have the two argii write to the same file, that will generate a
corrupt output file, have a radium() or a ra() read from the 2
argii and have it write out to the output file (single writer model
is the best way to go).

The rest of this email talks about multiple interfaces in general
and offers some new features.  Hopefully you will find it useful.

Carter


There are two fundamental concepts to deal with when reading
multiple interfaces at the same time.  And it all boils down to
monitor scope.

The concept right now is that the argus source id (srcid) identifies
the scope of an argus monitor, and the scope is limited to
a single interface.

Currently when a single argus opens multiple interfaces
( use multiple "-i int" options on the command line or in the
  argus.conf file),  argus tracks the packets as if they came from a
single interface.  When it reports total packets received, dropped,
etc... it pools the statistics from each interface its reading from, so
it really is treating the multiple interfaces as if they are a single
interface.  Now there are a lot of machines that do "bonding" or
"striping" and so this a legitimate strategy.  Currently, argus
doesn't track the interface the packet came in on, as that scoping
is implicit in the concept of a single argus a single source id.

If you don't track the interfaces, you basically are doing what the
libpcap "any" interface is doing.   You are saying you want argus to
treat the group of interfaces as a single entitiy.  This allows for  
simplicity
etc... and makes it trivial for argus.  But, .....

If you pool the packets, you will never really know where a packet
comes from or goes, when there are multiple active interfaces,
and if the box is supporting routing or forwarding (we have argii in
opensource routers and openWrt boxes, so we  do need to be sensitive
to this), and you pool, you will get double counting on flows (packet
counted coming in on one interface and counted again as it goes out
the other).

Running independent argii on each interface guarantees that you
track flows correctly, but adds additional infrastructure issues.   
Multiple
source id's, multiple sockets, and the need to run radium.
Now, I actually like that level of complexity for a number of reasons,
but for practical reasons, it kinda sucks....

When argus opens multiple interfaces, as it reads packets and
tracks flows, it knows what interface the packets came from, but
it tosses that information, when it generates the output record.
Its redundant information because of the concept of srcid and
monitor scoping.  Because argus has the basic information, it
could easily handle each interface independently.

The only issue is how do you discriminate the traffic from this
single argus.  Do you keep our current monitor scope strategy
where flows tracked from different interfaces get different "srcid"s,
or do we add the interface ifIndex to the argus record.

There are two BIG issues with adding ifIndex's to the argus record.
First is, there is no standard way of generating ifIndex's on PC's
and Linux machines.  (do you get the interface device names and
sort them and then dole out indexes sequentially?  or  do you use
SNMP strategies?  or do you just invent your own mapping?)

The second is the biggest issue.  We'll have to somehow propagate
the ifIndex meanings/semantics around.  This is trivial in terms of
transport, but not so easy when you post process the data, such as
storing, filtering, aggregating, archiving, compressing, etc... we'll  
have
to propagate the semantics of what the ifIndex mean.  ......

Just a little complicated.

So, I can add an ifIndex to argus-3.0, but we'll need to decide how
to generate and report the mapping of ifIndex and what interface
it really is.    And we can worry about propagating the semanic of the
ifIndex for later client updates.

And of course, we would need to decide how to configure it.
Maybe this is a argus-3.1 idea?



On Oct 11, 2007, at 8:43 PM, Lauro, John wrote:

> I vote for second strategy.  (or at least as a documented option to do
> it if not made the default)
>
> I am running argus on linux, and was wondering if there was a way to
> open more/all interfaces, but just didn't bug the list yet for
> suggestions...  Right now I run 3 separate argus processes, one for
> each interface...  Can something be specified with -i on argus?  I
> just tried -i any, and although argus started running, it didn't put
> any flow info in the logs...
>
> On the subject of multiple interfaces, how best do you merge the
> multiple streams (either live into one logfile, or just merging the
> log files would be fine)?  I only tried once, and it ended up creating
> double the flows...
>
>
>
>> -----Original Message-----
>> From: argus-info-bounces at lists.andrew.cmu.edu
> [mailto:argus-info-bounces at lists.andrew.cmu.edu] On
>> Behalf Of Carter Bullard
>> Sent: Thursday, October 11, 2007 6:09 PM
>> To: Argus
>> Subject: [ARGUS] default interfaces to monitor
>>
>> Gentle people,
>> We are free to modify some of argus's behaviors for the 3.0
>> release and I'd like to get some feedback on what argus does
>> when you don't give it an interface to monitor.
>>
>> Currently, argus opens the first interface that it finds, by using
>> pcap_lookupdev(buf).  That is what tcpdump() does, and so there
>> is some precedence.  However, there are alternatives.
>>
>> The first could be that it prints out the possible interfaces and
>> exists.  Argus
>> currently does this on Cygwin, because the interface names are so
>> hideous.
>>
>> The second strategy is that it could open all the interfaces it
> finds.
>> This is an interesting scenario with its own issues (does argus
>> pool all the packets like the Linux "any" interface, or does it pass
>> into the flow modeler the interface id, which becomes a part of the
>> flow key)?
>>
>> The third would be to do what it is doing right now (the zeroth
> strategy
>> I guess ;o).  My vote is to keep this behavior, and code up a change
> for
>> argus-3.1 but if the community has a strong opinion, then I'll make
>> a change.
>>
>> Do we have a vote/opinion/reaction/suggestion/comment?
>>
>> Carter
>