[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200606181309.k5ID9g7C032666@turing-police.cc.vt.edu>
Date: Sun Jun 18 14:09:55 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Sniffing on 1GBps
On Sun, 18 Jun 2006 17:58:32 +0530, crazy frog crazy frog said:
> I m just wondering if it is possible to capture the data from a
> highspeed NIC card?if it is possible then wht kind of precaution we
> have to take so that we does not miss the data?
What you need:
1) A NIC that can *sustain* 1GBps (did you mean 1Gbps? GB is giga-BYTES,
Gb is giga-BITS. 1Gbps is getting to be pretty standard). The two end
cases you want to test are (a) back-to-back jumbograms, and (b) back-to-
back *minimum* sized packets. Often, the second will make the card fall over
even though the actual data transfer is far lower, due to the increased
interrupt rate. Non-buggy device drivers help a lot here, as does the
ability to buffer multiple packets per interrupt.
2) Is full packet capture required, or just the IP/TCP/UDP headers? It
makes a big difference for data storage requirements. Similarly, if
you can limit the traffic captured (a given hostname, a port, anything
else that makes sense as a tcpdump or iptables filter, tec), it makes the
job easier.
3) A disk subsystem that can *sustain* 125 MB/sec write rates (you'll
probably need to stripe across several disks. Also, you'll need to
think *really* hard if you need continuous full storage - even an hour
of 125 MB/sec gets pretty honking huge....
4) If you're trying to catch off the wire at 125MB/sec, and throw it *all*
to a disk, you'll be wanting to look at high-end PCI. Quite possibly a
dual-backplane system, and watch out for memory contention issues...
5) You'll need something to *process* the data as well - which gets *really*
interesting if you're trying to do it real-time.
Having said that, 1Gbps capture isn't particularly technically challenging.
There's people out there that are looking at the 10Gbps and 40Gbps markets
(these usually involve some custom silicon to do filtering so you don't
try to capture the *entire* data capacity - think "Snort rules in hardware").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060618/02320468/attachment.bin
Powered by blists - more mailing lists