<div><div dir="auto">When I answered this post originally, it got me thinking:</div></div><div dir="auto">If you set queues with your suricata start command, how does suricata coordinate queue distribution across the IPTABLES “—queue-balance 0:3” portion of the iptables command. </div><div dir="auto">If one was to also add “—queue-cpu-fanout” option to the iptables command, would that break the way iptables interacts with Suricata or cause unpredictable behavior? Or would it help optimize. As I understand things, the queue balance functionality can be based on flows OR CPUID.</div><div dir="auto"><br></div><div dir="auto">Maybe this needs to be forked to a separate post, but I found this detail intriguing.</div><div dir="auto">Thoughts??</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 8:57 AM Chris Boley <<a href="mailto:ilgtech75@gmail.com">ilgtech75@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">I’m not 100% sure if suricata does auto load balancer functionality on cores by default now? Maybe it does. I’m no SME on Suri. </div><div dir="auto"><br></div><div dir="auto">In nfqueue mode, can you not set —queue-balance 0:3 in iptables and run Suricata like; <span style="font-family:Meiryo,メイリオ,"Hiragino Sans",sans-serif;word-spacing:1px;background-color:rgb(255,255,255)"> </span><span style="font-family:Meiryo,メイリオ,"Hiragino Sans",sans-serif;word-spacing:1px;background-color:rgb(255,255,255)">suricata -c /etc/suricata.yaml -S /etc/suricata/sample.rules -q 0 -q 1 -q 2 -q 3 -</span><span style="font-family:Meiryo,メイリオ,"Hiragino Sans",sans-serif;word-spacing:1px;background-color:rgb(255,255,255)">vv ? </span></div></div><div dir="auto"><span style="font-family:Meiryo,メイリオ,"Hiragino Sans",sans-serif;word-spacing:1px;background-color:rgb(255,255,255)"><br></span></div><div dir="auto"><span style="font-family:Meiryo,メイリオ,"Hiragino Sans",sans-serif;word-spacing:1px;background-color:rgb(255,255,255)">I was under the impression that nfqueue mode load balancing was achieved in this way? My thoughts on this are probably outdated. Could we help his performance by offering that as a method? </span></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 8:20 AM Amar Rathore - CounterSnipe Systems <<a href="mailto:amar@countersnipe.com" target="_blank">amar@countersnipe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">Hello Tanaka</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">The configuration you have described is something we use all the time. It seems to work fine for us...even with most of the rules loaded.</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">The main reason for bridging is the flexibility it offers....we bridge 6 interfaces together and any one of the can be in or out. Have to say we are still on a previous version.</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">I notice that you are loading 1 rule specifying the HOME_NET variable, have you tried running with no rules loaded at all? Just to see if the base configuration is all ok? </p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">Have you configured the HOME_NET variable?</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">Is there a specific reason for using 'reject' as opposed to 'drop'?</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">If all of that is good, then it may be something to do with V4.</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">Just some thoughts.</p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)"><br>Amar Rathore </p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)"><a href="mailto:amar@countersnipe.com" target="_blank">amar@countersnipe.com</a></p><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:rgb(0,0,128)">Delivering Suricata based Network Security.</p></div><div><blockquote type="cite">On June 28, 2018 at 3:34 AM tanaka yusuke <<a href="mailto:net1234@hotmail.co.jp" target="_blank">net1234@hotmail.co.jp</a>> wrote: <br> <br><div id="m_8875291497078023758m_2849963984198129795ox-77fe71ee48-divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Meiryo,'\0030e1\0030a4\0030ea\0030aa','Hiragino Sans',sans-serif" dir="ltr"><p style="margin-top:0;margin-bottom:0"> <br></p><div>Hi. <br> <br> I am trying to build an IPS box at work using suricata, but my suricata box is showing very poor performance for some reason. <br> <br> Measured performance with wrk (<a href="https://github.com/wg/wrk" target="_blank">https://github.com/wg/wrk</a>) in isolated testing environment like this: <br> <br> client ---> suricata box ---> server <br> <br> With default suricata.yaml, the box throughput drops below 10% of a dumb bridge configuration. <br> I tried to tweak some of suricata.yaml settings and found improvement somehow but still way too low. <br> I would appreciate if you have any other suggestions for performance improvement. <br> Thanks in advance. <br> <br> Suricata box: <br> OS: CentOS 7.5 (simple install) <br> suricata: version 4.0.4 (suricata-4.0.4-1.el7.x86_64) <br> CPU: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz (4Core/4Thread) <br> <br> Suricata launch procedure: <br> #> systemctl stop firewalld <br> #> iptables -A FORWARD -J NFQUEUE --queue-num 0 <br> #> suricata -c /etc/suricata.yaml -S /etc/suricata/sample.rules -q 0 -vv <br> <br> Rules activated (/etc/suricata/sample.rules) <br> reject ip $HOME_NET any -> 192.168.10.142 any (msg:"test rules"; gid:10000; sid:10000; rev:1;) <br> <br> Testing patterns: <br> 1. suricata off (dumb bridge mode) <br> 2. suricata on (default suricata.yaml) <br> 3. suricata on (log suppressed) <br> 4. suricata on (log suppressed + cpu-affinity set) <br> <br> Results: <br> [client]# ./wrk -t10 -c1000 -d30s <a href="http://192.168.100.101/" target="_blank">http://192.168.100.101/</a> <br> Running 30s test @ <a href="http://192.168.100.101/" target="_blank">http://192.168.100.101/</a> <br> 10 threads and 1000 connections <br> <br> 1. 3296109 requests in 30.09s, 3.20GB read <br> Requests/sec: 109536.50 <br> Transfer/sec: 108.85MB <br> <br> 2. 229685 requests in 30.10s, 228.24MB read <br> Requests/sec: 7630.75 <br> Transfer/sec: 7.58MB <br> <br> 3. 341039 requests in 30.04s, 338.90MB read <br> Requests/sec: 11354.15 <br> Transfer/sec: 11.28MB <br> <br> 4. 417160 requests in 30.03s, 414.54MB read <br> Requests/sec: 13892.03 <br> Transfer/sec: 13.80MB <br> <br> Modifications to suricata.yaml: <br> <br> 3. suppressed log output <br> ----------------------------------------- <br> stats: <br> enabled: no <br> outputs: <br> - eve-log: <br> enabled: no <br> ----------------------------------------- <br> <br> 4. cpu-affinity setting added <br> ----------------------------------------- <br> threading: <br> set-cpu-affinity: yes <br> cpu-affinity: <br> - management-cpu-set: <br> cpu: [ "all" ] <br> prio: <br> default: "low" <br> - receive-cpu-set: <br> cpu: [ "all" ] <br> prio: <br> default: "low" <br> - worker-cpu-set: <br> cpu: [ 1,2,3 ] <br> mode: "exclusive" <br> threads: 3 <br> prio: <br> default: "medium" <br> - verdict-cpu-set: <br> cpu: [ 0 ] <br> prio: <br> default: "high" <br> ----------------------------------------- <br> <br></div><br><p> <br></p></div></blockquote><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:#000080" class="m_8875291497078023758m_2849963984198129795default-style"><br> </p><blockquote type="cite">_______________________________________________ <br>Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a> <br>Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a> <br>List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a> <br> <br>Conference: <a href="https://suricon.net" target="_blank">https://suricon.net</a> <br>Trainings: <a href="https://suricata-ids.org/training/" target="_blank">https://suricata-ids.org/training/</a></blockquote><p style="font-size:12pt;font-family:arial,helvetica,sans-serif;color:#000080" class="m_8875291497078023758m_2849963984198129795default-style"><br> </p></div>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div></div>
</blockquote></div></div>