default interfaces to monitor

Peter Van Epp vanepp at sfu.ca
Fri Oct 12 10:36:28 EDT 2007


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



More information about the argus mailing list