What to do in this situation

[Carter Bullard]

Hey Neil,
   The real question I suppose is this. "Is the file
writing of such importance, that if it fails, then
argus should exit?"  I think the answer is yes.

   If writing out to the file is just incapable of
keeping up with the load, then tossing records
seems like the right thing to do, rather than stopping.

   I'm pretty convinced that the errors that we've been
seeing lately can be resolved with tuning max queue
depth values, error tolerance and back off scheduling.
Argus-2.0.0 can use some performance improvements,
but what we gain with the queues and processes is much
better than what we had with 1.8, in terms of reliability
and packet processing performance under load (at least
when we get these bugs out of the way ;o)

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com


> -----Original Message-----
> From: Neil Long [mailto:neil.long at computing-services.oxford.ac.uk]
> Sent: Thursday, March 15, 2001 7:27 AM
> To: Carter Bullard
> Subject: Re: What to do in this situation
> 
> 
> I would hate to not have data if such an event happened. With v1.8 I
> see the argus process grow in memory (and not shrink) if 
> there has been
> a syn flood attack using spoofed IPs - the size of the data file is a
> dead give away.
> 
> To resolve the problem I suspect we will need to know the cause - I
> would have 2 hosts logging - v1.8 and v2 and try and make sense based
> on data - comes of being an experimentalist ;-)
> 
> I would guess that a 'dump what you can, kill and restart' sequence is
> best especially if the network access process can continue.
> 
> Neil
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Dr Neil J Long, Computing Services, University of Oxford
>  13 Banbury Road, Oxford, OX2 6NN, UK Tel:+44 1865 273232 
> Fax:+44 1865 273275
>  EMail:       Neil.Long at computing-services.oxford.ac.uk  
>  PGP:    ID 0xE88EF71F    OxCERT: oxcert at ox.ac.uk PGP: ID 0x9FF898D5
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20010315/5a00ee87/attachment.html>