<div dir="ltr"><div><div><br><br>On Thu, Jun 26, 2014 at 9:22 AM, Victor Julien <<a href="mailto:lists@inliniac.net">lists@inliniac.net</a>> wrote:<br>> On 06/26/2014 09:19 AM, Peter Manev wrote:<br>>> On Wed, Jun 25, 2014 at 3:37 PM, Kurzawa, Kevin<br>
>> <<a href="mailto:kkurzawa@co.pinellas.fl.us">kkurzawa@co.pinellas.fl.us</a>> wrote:<br>>>> Using pcap because ... well, I don't know any better? I guess I don't really know the alternatives. PF Ring is the other option right?<br>
>><br>>> There is pcap, pf_ring and af_packet.<br>>><br>>> af_packet works "out of the box", just make sure your kernel is not<br>>> older than 3.2.<br>>> runmode: workers seems to be the best option for af_packet.<br>
>><br>>> For pf_ring you need to compile and make a module, also make sure your<br>>> kernel is not older than 3.0 (2.6.32 being the bare minimum)<br>>> runmode: workers seems to be the best option for pf_ring as well.<br>
>><br>>><br>>> Our wiki provides some guidance -<br>>> <a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki">https://redmine.openinfosecfoundation.org/projects/suricata/wiki</a><br>
>> and then there are a number of articles on the net and on our user<br>>> mail list archives regarding high perf tuning.<br>>><br>>>><br>>>> Is this the potential source of the tcp.reassembly_gap?<br>
>><br>>> No<br>><br>> Uh, yes? Packet loss is certainly a big factor in tcp.reassembly_gap.<br>> Stats do show packet loss, so using a faster capture method may<br>> certainly help.<br>><br><br>
<br>It may help.<br><br>Judging by the posted output -><br>The number of tcp.reassembly_gap<span class=""></span><span class=""></span> is 4 times higher than the number of capture.kernel_drops <br></div>Based on that I drew the conclusion. <br>
In my observations/experience in general most of the cases of big numbers in the reassembly gaps (and much smaller number of kernel drops) counter are due to ... well :) gaps in the traffic - either there were drops on the mirror port or there was sudden peaks/fluctuations in the traffic and the mirror port reached limits and similar things.<br>
<br>If we look at it from purely factual perspective in this case - how can one dropped packet (and it may be any packet not just tcp) get to 4 reassembly gaps?<br><br></div>Thanks<br><div><div><div><br><br><br><br>-- <br>
Regards,<br>Peter Manev</div></div></div></div>