default interfaces to monitor

[Carter Bullard]

On the 10-gig Endace cards, you can get them pretty well time
sync'd by connecting their time sync interfaces together and having
one of the them sync the other (is that the dag_duck stuff? ;o).  We've
done quite a bit of this and it works well,  but haven't done anything
less than mid (50-100) microsecond sync, as I personally did that work
years and years ago, using pretty old cards.

No need for GPS sync for this, as we don't need accuracy, just
precision.  But if you have an external GPS sync, and split the
trigger to the two cards, you get in the lower microsecond sync
on the cards.

Carter



On Oct 12, 2007, at 10:36 AM, Peter Van Epp wrote:

> On Fri, Oct 12, 2007 at 10:03:56AM -0400, Carter Bullard wrote:
>> 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
> 	
> 	I've been running argus with dual NIC cards from taps for years, but
> there is yet another issue that bites you unless you have Endace  
> cards (or
> others that time stamp on board): the packets can arrive out of  
> order at the
> argus because of CPU and interrupt scheduling. Its perfectly  
> possible for there
> to be multiple packets in the enet card buffer when the interrupt  
> gets processed
> (especially on a fast link with a busy processor). That means you  
> may get a
> packet (which will then get the current kernel time stamp because  
> the card
> doesn't time stamp packets) that is in fact a reply to a packet  
> that is sitting
> in the on card buffer in the second enet card that hasn't been read  
> yet (and
> will have a later time stamp when it does get read). Carter has  
> added code in
> 3.0 to try and deal with this issue, but the only really correct  
> answer is an
> Endace card that stamps the packet in the internal buffer with an  
> on board
> time stamp when the packet arrives (rather than when the interrupt  
> gets
> serviced) and processes both sides of the connection on the same  
> card (this of
> course fails on the OC192 cards which are single interface, but  
> then I expect
> you need the GPS time source option to give them a better chance of  
> being
> correct :-)).
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>