[unisog] DDoS IRC bots

Peter Van Epp vanepp at sfu.ca
Fri Mar 7 16:33:58 GMT 2003


On Fri, Mar 07, 2003 at 10:19:12AM -0500, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 06 Mar 2003 21:32:01 PST, Peter Van Epp said:
> > (www.oarcorp.com) is one possible answer I keep meaning to explore. A simple 
> > OS that does nothing but read packets in from the interface and write the 
> > packet (in tcpdump format for time stamps etc. but with no interpretation or 
> > context/ memory space switches (and thus no copys) to a file system (or raw
> > disk if needed for performance which it might be) would be a thing of beauty.
> 
> That *would* be pretty slick.. ;)
>  
> > You of course then run headlong in to disk performance issues, but throwing 
> > money at it (probably in the form of a raid like parallel disk farm) should 
> > cure that. One day in the far future when there is time :-).
> 
> Every 4-6 months, somebody will come on the NANOG list and ask why a Cisco
> router costs $moby when the CPU isn't anywhere near as fast as the average
> desktop machine, and why you couldn't make a cheaper router using an x86 and
> a few PCI network cards.  Hilarity ensues, and somebody gets to explain
> to the newbie that the bits have to come in and go out over the PCI bus,
> and invite them to do the calculation of 2xgigE and compare it to the
> maximum bandwidth of the PCI, and ask what component will hit starvation
> first, the inbound interface, the outbound (disk in this case), or CPU...
> -- 
> 				Valdis Kletnieks
> 				Computer Systems Senior Engineer
> 				Virginia Tech
> 

	Yep, I don't know whether the 1.6 gig limit is OS related, benchmark
(netpipe) related or memory/PCI/DMA (I'm pretty sure it isn't NIC card related
:-)) in the machine. The CMU folks running argus on Gig links tell me that 
it is necessary to run the sensor in network mode (i.e. the compressed data
stream from the Gig link is written via a second NIC to another box where it
is stored to disk by another argus task listening at around 1/100th of the
input bandwith after argus has processed it) because the bus/memory bandwith 
taken by the DMA controller writing blocks to disk causes packet loss 
at high volumes. You are straining pretty much everything in a PC at full 
tilt boggie gig, you only have around 8 memory cycles in DRAM for instance
(and that assumes the fancy internal interleaved DRAM) which is one reason why
eliminating the kernel/user copy is a big win. Thats before even considering
PCI and PCI bridge chip limitations. I suspect in a real network that a 
sufficient amount of ram (so that you can buffer traffic peaks) and only 
trying to do a single GIG side (i.e. two boxes per GIG link one of tx and one 
for rx) would be required, but that said I think you could keep up. It will 
certainly be exciting from a systems engineering stand point, you need to 
understand motherboard chipsets and data path limitations really really well ...

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada



More information about the unisog mailing list