differences between 2.0 and 1.8 logs

[Peter Van Epp]

> 
> 
> 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