Stability problems.

[Chris Newton]

Thanks Carter for hte patches, I haven't hecked it out yet...

  On the topic of the testing tool... I'd be very interested, and have the 
resources (time, people, hardware), to test this...  I would imagine it would 
be of great interest to everyone here.

  Can we give it a try?  I really need to know how big a link I can reliably 
handle, and how many packet/sec during a DDoS

Chris

>===== Original Message From <carter at qosient.com> =====
>Hey Peter,
>   I've measured well above 25-30K pps using Redhat kernels,
>so I'm interested in their numbers as well!
>
>   Actually, Argus may not get toooo confused in your
>scenario, as it deals with out of order packets pretty
>well.
>
>   Can you generate a DDOS simulator with your tools?
>
>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: owner-argus-info at lists.andrew.cmu.edu
>[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Peter Van
>Epp
>Sent: Thursday, June 07, 2001 11:45 AM
>To: argus
>Subject: Re: Stability problems.
>
>
>	A possibly unrelated point: in the latest Usenix login: there is
>a
>conference report from the Linux kernel developers conference (which one
>would not expect to be biased against Linux :-)). The point of interest
>is a
>discussion that the Linux 2.4 kernel hangs at around 24K PPS yet a BSD
>kernel doesn't hang until 200K PPS. They didn't specify a link speed
>(possibly gig), but this flys in the face of measured experience here
>(Linux does at least as well and usually better than FreeBSD), It is
>also unclear (although one wouldn't expect it at a kernel developer's
>conference) what board/drivers this was with. Some drivers exhibit this
>behaviour (Realtec and the 3Com 3c905 driver) but there are better
>drivers.
>	More related to Chris's problem: I have a patch set which will
>allow tcpreplay to simulate a full duplex link using two capture files
>and two
>Enet cards. When last I tried it (some time ago) with a single IDE disk
>it would do about 160 megs per sec (likely disk limited). The fly in the
>ointment is that you would need to carefully adjust the capture files to
>start
>identically in order to run the files at full speed (otherwise the reply
>packets can come in before the packet that caused it goes out, which
>would undoubtably confuse argus). Somewhere down my list of interesting
>things to do is write a "dump file optimiser" that would deal with this
>(i.e. reorder the packets in a tcpdump file so that the packet sequence
>will be correct when played back at full speed) but it hasn't even been
>started yet.
>	Given this and a test bed you can effectively test the failing
>case (since you know all the packets that should appear) and see where
>(if anywhere) you are losing things and what you are losing.
>
>Peter Van Epp / Operations and Technical Support
>Simon Fraser University, Burnaby, B.C. Canada

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Chris Newton, Systems Analyst
Computing Services, University of New Brunswick
newton at unb.ca 506-447-3212(voice) 506-453-3590(fax)

"The best way to have a good idea is to have a lot of ideas."
Linus Pauling (1901 - 1994) US chemist