[Oisf-users] (no subject)

[Peter Manev]

On Sun, Jun 8, 2014 at 11:01 AM, Christophe Vandeplas
<christophe at vandeplas.com> wrote:
> Hi,
>
>
> What kind of drop do you have?
> - capture.kernel_drops
> - tcp.segment_memcap_drop
> - tcp.ssn_memcap_drop
>
> Lower the number of threads in the af-packet section to the number of
> cores your system has. (cat /proc/cpuinfo |  fgrep processor | wc -l )
>
> Run suricata with no rules, and tweak the configuration, you should
> have (almost) no packet drop before you activate rules.
>
> After having made changes in the yaml configuration file I usually:
> - stop suricata
> - empty the logfiles
> - start suricata
> This way there's no risk of looking at older logs and misinterpreting
> configuration changes.
>
>
> If possible, link your stats.log to a monitoring tool to greate
> graphs. This way you can correlate packet drops by suricata with other
> events on the system. I've written an article about this :
> http://christophe.vandeplas.com/2013/11/suricata-monitoring-with-zabbix-or-other.html
>  But also other scripts exist.
> Make sure you edit the suricata_stats.py script with the number of
> threads configured in suricata.yaml
>
>
> If your drops are capture.kernel_drops, then :
> Have you read this article?
> http://christophe.vandeplas.com/2013/11/suricata-capturekerneldrops-caused-by.html
> Please do the first part "Confirmation of the problem" and see if you
> also have the problem caused by the lack of NIC queues.
> In a few words:
> - start suricata
> - as root, run  "top -H" and check how many AFPacketethXX threads are
> generating load.
> - if it's only one thread, then the problem has been pinpointed.
> However working with cluster_flow should solve this problem. Make sure
> you read the rest of the article then.
>
>
> Kind regards
> Christophe
>
>


Can you share your suricata.log as well please?
What is the output of
ethtool -k your_interface
?