Date: Mon, 28 Apr 2008 17:13:20 +0800 From: Ganbold <ganbold@micom.mng.net> To: Vlad GALU <dudu@dudu.ro> Cc: freebsd-net@freebsd.org Subject: Re: capturing packets on 250mb link Message-ID: <48159530.4080908@micom.mng.net> In-Reply-To: <ad79ad6b0804280202n50832c0ex866cac2fdff525c5@mail.gmail.com> References: <48154EA2.6070105@micom.mng.net> <ad79ad6b0804280101t12ccc191g3d4fe3e4ff2a7427@mail.gmail.com> <4815919A.5070607@micom.mng.net> <ad79ad6b0804280202n50832c0ex866cac2fdff525c5@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Vlad GALU wrote:
> On 4/28/08, Ganbold <ganbold@micom.mng.net> wrote:
>
>> Vlad,
>>
>>
>> Vlad GALU wrote:
>>
>>
>>> On 4/28/08, Ganbold <ganbold@micom.mng.net> wrote:
>>>
>>>
>>>
>>>> Hi all,
>>>>
>>>> What is the best way to capture packets on 250mb link?
>>>> What kernel features/modules or tools (less CPU/RAM overhead) should I
>>>>
>> use?
>>
>>>>
>>> Given your OS version, I'd say that setting the BPF buffer size to
>>> around 1MB and setting the monitor flag on the capture interface would
>>> give you very good results. In that combination we've been doing
>>> packtet capture at gigabit speeds without packet loss.
>>>
>>>
>>>
>> Thanks Vlad. So then it means something like following will work in our
>> case:
>>
>> #sysctl net.bpf.bufsize: 1048576
>> #ifconfig bge1 monitor up
>> #tcpdump -i bge1 -s0 -w capture.log -C 2048 -W 100
>>
>> Correct me if I'm wrong here.
>>
>
>
> Yes, it should do the job. However I can't understand why you want
> a snaplen of 0, as 68 should be the minimum to accomodate the
> ethernet+ip+tcp/udp headers.
>
Thanks Vlad.
According to tcpdump(1):
-s Snarf snaplen bytes of data from each packet rather
than the
default of 68 (with SunOS's NIT, the minimum is
actually 96).
68 bytes is adequate for IP, ICMP, TCP and UDP but may
truncate
protocol information from name server and NFS
packets (see
below). Packets truncated because of a limited
snapshot are
indicated in the output with ``[|proto]'', where proto
is the
name of the protocol level at which the truncation has
occurred.
Note that taking larger snapshots both increases the
amount of
time it takes to process packets and, effectively,
decreases the
amount of packet buffering. This may cause packets to be
lost.
You should limit snaplen to the smallest number that
will cap-
ture the protocol information you're interested in.
Setting
snaplen to 0 means use the required length to catch whole
pack-
ets.
Ganbold
>
>> thanks,
>>
>> Ganbold
>>
>>
>>
>>
>>>
>>>> I have FreeBSD 7.0-STABLE machine (
>>>> CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2822.51-MHz 686-class CPU),
>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>> 1GM RAM, ad2: 76319MB <Maxtor 6L080M0 BANC1G10> at ata1-master
>>>>
>> SATA150).
>>
>>>> #uname -an
>>>> FreeBSD ng1.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #3: Sat Apr 26
>>>> 14:08:06 ULAT 2008 tsgan@ng1.micom.mng.net:/usr/obj/usr/src/sys/NG
>>>>
>> i386
>>
>>>> #pciconf -lv|more
>>>> ...
>>>> bge0@pci0:2:0:0: class=0x020000 card=0x1659103c chip=0x165914e4
>>>> rev=0x11 hdr=0x00
>>>> vendor = 'Broadcom Corporation'
>>>> device = 'BCM5721 NetXtreme Gigabit Ethernet PCI Express'
>>>> class = network
>>>> subclass = ethernet
>>>> ...
>>>>
>>>> Are there any considerations on hardware?
>>>>
>>>> thanks in advance,
>>>>
>>>> Ganbold
>>>>
>>>> --
>>>> Cats, no less liquid than their shadows, offer no angles to the wind.
>>>>
>>>> _______________________________________________
>>>> freebsd-net@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to
>>>> "freebsd-net-unsubscribe@freebsd.org"
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Look out! Behind you!
>>
>>
>
>
>
--
Slowly and surely the Unix crept up on the Nintendo user ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48159530.4080908>