capturing packets on 250mb link

[Ganbold]

Vlad GALU wrote:
> On 4/28/08, Ganbold <ganbold at micom.mng.net> wrote:
>   
>> Vlad,
>>
>>
>>  Vlad GALU wrote:
>>
>>     
>>> On 4/28/08, Ganbold <ganbold at 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 at ng1.micom.mng.net:/usr/obj/usr/src/sys/NG
>>>>         
>> i386
>>     
>>>>  #pciconf -lv|more
>>>>  ...
>>>>  bge0 at 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 at freebsd.org mailing list
>>>>  http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>>  To unsubscribe, send any mail to
>>>> "freebsd-net-unsubscribe at freebsd.org"
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>>  --
>>  Look out! Behind you!
>>
>>     
>
>
>   


-- 
Slowly and surely the Unix crept up on the Nintendo user ...