argus-2.0.0f phase 2

[Carter Bullard]

Gentle People,
   There is a new argus-2.0.0j on the server at
ftp://qosient.com/dev/argus/argus-2.0/argus-2.0.0j.tar.gz
that I have just put up.  Wed Sept 27 22:30:00.
This has many improvements and includes ethernet addresses.
The filters all should be working now, (syn, fin, ether src)
and many cosmetics have been done for consistency of output.

   Some packet counting inconsistencies have been resolved,
and there were some real winners in this lineup.  There
may still be a few lurking, but some major problems may have
been solved.

   Still needing to find the time corruption problem, but
that is for tomorrow.

   Remember argus-2.0.0f is not compatible with previous
versions, so do be careful to throw out any stale data,
apps.


Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 17A
New York, New York  10022

carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
Sent: Wednesday, September 27, 2000 7:38 PM
To: argus
Subject: Re: RE: differences between 2.0 and 1.8 logs


>
>
> On Wed, 27 Sep 2000 07:13:01 -0400 Carter Bullard <carter at qosient.com>
> wrote:
>
> > Hey Russell,
> >    Hmmmmmm, it is highly unlikely that we're missing the
> > packets, at least not that many, and with such selectivity
> > unless there is a huge difference between the 2.0 and the
> > 1.8 output files.   We could be missing the Argus records.
> > Is this a heavily loaded network?  Hmmmmmmmmmm.
>
> Not by Peter's standards ;-)  It's a 10MB network with about 4Mbps real
> traffic with peaks much higher.  The box has a 500MHz processessor and
> 128MB memory, runs snort and argus 1.8.1 as well as argus 2.0.  CPU
> sits at around 5%, except when I run raconnections and gzip on the hour
> (I am compacting and compressing the 1.8.1 logs but not the 2.0).

	I wouldn't expect problems on this link, the box that I did the
performance test with is a 600 meg box with 512megs of RAM and UDMA66 IDE
disk. While I had one less argus task running, the tcpdump with a -s1520
snaplength should be equivelent to snort and it did ok at the 20 megabit
level (which should cover full duplex 10) it only started to have troubles
at 30. Come to think of it, there is another argus task there (worse than
yours in fact) looking at the backbone at 100 megs on another interface.
In terms of internal box level load that should be worse than your state
and it still didn't start losing til 30megs (and I should kill the other
argus server and see if performance improves come to think of it :-)).
	One question is what ethernet cards are you using? I have both cheapo
Realtek (Allied Telesyn) and 3com905B 10/100s in, both of which will do
close
to 100 on ttcp/tcpreplay. Some of the other cards are reputed to have
performance problems. It is probably worth trying a ttcp between boxes when
your new box appears to make sure you can saturate 10 and the cards aren't
quietly losing packets on you. At 10 the WD8013 was considered a good card
(I have a bunch of them at home and I beleive I did verify I could saturate
the wire at 10 with them). You might want to try boosting RAM as well (a
test
with RAM from the new box for instance) and see if that helps, it may be
feeling cramped with internal kernel tables which it has sized down for
available RAM and that probably won't show up as a lack of system ram.
	I still need to get to putting up OpenBSD and seeing if it captures
better than FreeBSD because I recall a change in the FreeBSD bpf code a year
or two ago.

>
> I am also having trouble with running out of swap space  when I have
> all three processes running.  I think it may be raconnections causing
> problems because normally there is heaps of free memory and almost no
> swap space used.  However this does not tally with the last modified
> time stamp on the output file which don't cluster shortly after the
> hour as one would expect if it was raconnections that was using up the
> swap space.
>
> I have just this morning taken delivery of two new boxes, and I try and
> get one of them set up along side the exising one and duplicate the
> setup.  Currently this box is the only one with enough grunt to run
> snort comfortably.
>
> >
> >    The man records also record the number of packets seen and
> > the totals in the flow records should add up to the totals
> > in the man records.
>
> Hmmm... I have never seen a final report from argus, it always dies
> first.  Here are the man records from the last run
>

	Back about h or i I stopped seeing any seg fault endings. Whatever
was current last night survived for at least 12 hours on my 100 link without
seg faulting (and was manually stopped at that) and theres all sorts of
strange things (IPX, Appletalk, Vines, Netbui probably Decnet, likely runt
packets because I haven't beaten all of our duplex issues down yet) on that
link. Are you seeing the seg fault where the initial thread dies and the
other
two linger still?

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000927/35c88bfb/attachment.html>