[Oisf-users] Tuning Suricata (2.0beta1) -- no rules and lots of packet loss

Wed Aug 21 16:52:20 UTC 2013

No, it doesn't work, at least in the sense of only 1% packet loss being
considered a success.  Something odd with the Intel cards is preventing
more than 16 hardware queues from being used as the system will only show
activity with 16 cores in workers mode, all other CPUs are 100% idle.  The
RSS parameter to the ixgbe module needs to be set for each port although it
claims to automatically use # of cores or # of ports, whichever is greater.
 Also again, about FdirMode=3.. I don't think it applies here.

I've since removed the additional cards and just experiment with one.
 autofp mode isn't working as I'd expect either.

Adjusting the MTU did reduce memory consumption.  I suppose that is meant
to reflect the average pMTU of flows and not the link connected to the
sensor.  The documentation could be written better to reflect this as that
part seems to imply something different.  (yes, reading more about MTU and
IDS from various sources makes it clear).  Regarding documentation the
af-packet section regarding the zero-copy ring size conflicting with
buffer_size should be updated; values that are commented out are assumed to
be 'defaults' like in many other configuration scenarios;  I'm glad you
pointed this out as it is definitely not apparent to me from just looking
at the configuration.

I'm going to go away now to read code and experiment more.

--TC

autofp Example:

capture.kernel_packets    | RxAFPeth41                | 7117283101
capture.kernel_drops      | RxAFPeth41                | 4885784393
capture.kernel_packets    | RxAFPeth42                | 7290835993
capture.kernel_drops      | RxAFPeth42                | 5061427961
capture.kernel_packets    | RxAFPeth43                | 7213432976
capture.kernel_drops      | RxAFPeth43                | 4941736439
capture.kernel_packets    | RxAFPeth44                | 7273721753
capture.kernel_drops      | RxAFPeth44                | 5046375696
capture.kernel_packets    | RxAFPeth45                | 7702660203
capture.kernel_drops      | RxAFPeth45                | 5473406098
capture.kernel_packets    | RxAFPeth46                | 6526210366
capture.kernel_drops      | RxAFPeth46                | 4280571057
capture.kernel_packets    | RxAFPeth47                | 7473635100
capture.kernel_drops      | RxAFPeth47                | 5264888903
capture.kernel_packets    | RxAFPeth48                | 8001217687
capture.kernel_drops      | RxAFPeth48                | 5781338601
capture.kernel_packets    | RxAFPeth49                | 7935510106
capture.kernel_drops      | RxAFPeth49                | 5684606164
capture.kernel_packets    | RxAFPeth410               | 6672471328
capture.kernel_drops      | RxAFPeth410               | 4480440331
capture.kernel_packets    | RxAFPeth411               | 4012330752
capture.kernel_drops      | RxAFPeth411               | 2650530005
capture.kernel_packets    | RxAFPeth412               | 6938284654
capture.kernel_drops      | RxAFPeth412               | 4686886437
capture.kernel_packets    | RxAFPeth413               | 7368646714
capture.kernel_drops      | RxAFPeth413               | 5117305059
capture.kernel_packets    | RxAFPeth414               | 5284771030
capture.kernel_drops      | RxAFPeth414               | 3751148947
capture.kernel_packets    | RxAFPeth415               | 7373582300
capture.kernel_drops      | RxAFPeth415               | 5176332364
capture.kernel_packets    | RxAFPeth416               | 7114510564
capture.kernel_drops      | RxAFPeth416               | 4903112771
capture.kernel_packets    | RxAFPeth417               | 68112
capture.kernel_drops      | RxAFPeth417               | 0
capture.kernel_packets    | RxAFPeth418               | 80839
capture.kernel_drops      | RxAFPeth418               | 0
capture.kernel_packets    | RxAFPeth419               | 77292
capture.kernel_drops      | RxAFPeth419               | 0
capture.kernel_packets    | RxAFPeth420               | 90287
capture.kernel_drops      | RxAFPeth420               | 0
capture.kernel_packets    | RxAFPeth421               | 78012
capture.kernel_drops      | RxAFPeth421               | 0
capture.kernel_packets    | RxAFPeth422               | 74278
capture.kernel_drops      | RxAFPeth422               | 0
capture.kernel_packets    | RxAFPeth423               | 79919
capture.kernel_drops      | RxAFPeth423               | 0
capture.kernel_packets    | RxAFPeth424               | 84155
capture.kernel_drops      | RxAFPeth424               | 0
capture.kernel_packets    | RxAFPeth425               | 84760
capture.kernel_drops      | RxAFPeth425               | 0
capture.kernel_packets    | RxAFPeth426               | 85328
capture.kernel_drops      | RxAFPeth426               | 0
capture.kernel_packets    | RxAFPeth427               | 81765
capture.kernel_drops      | RxAFPeth427               | 0
capture.kernel_packets    | RxAFPeth428               | 83583
capture.kernel_drops      | RxAFPeth428               | 0
capture.kernel_packets    | RxAFPeth429               | 91101
capture.kernel_drops      | RxAFPeth429               | 0
capture.kernel_packets    | RxAFPeth430               | 104013
capture.kernel_drops      | RxAFPeth430               | 0
capture.kernel_packets    | RxAFPeth431               | 92905
capture.kernel_drops      | RxAFPeth431               | 0
capture.kernel_packets    | RxAFPeth432               | 98068
capture.kernel_drops      | RxAFPeth432               | 0

On Sun, Aug 18, 2013 at 10:43 PM, Cooper F. Nelson <cnelson at ucsd.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> No problem and please let us know if the 'worker' mode config works for
> you.  I'm planning on building a 40gig sensor and it would help if I
> knew how it performed with multiple NICs.
>
> - -Coop
>
> On 8/16/2013 5:36 PM, Tritium Cat wrote:
> > Cooper,
> >
> > Thanks again for the explanations and supporting information.
> >
> > --TC
> >
>
>
> - --
> Cooper Nelson
> Network Security Analyst
> UCSD ACT Security Team
> cnelson at ucsd.edu x41042
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSEbCGAAoJEKIFRYQsa8FWC5oIAM4qY13/Yu0Q7idrbcB+073z
> eh/AnOVCOU1NJbqltdVRtLWh8JFhdyhglNAZI2HpHoCSiRRkzHw7YTnz7DPadETg
> mEpTOJvm9y9DKJzG6jp1eGRqBFwQ+yMWTtQwxyg4gl0tk95OxkGHo3Y7ok/ROa7+
> 1aRTnBDpkQ+HNeEBmI1Jw5rdf0gQ3jPuyhNLhF/cPNnTJ1YC6SyQE6DQSoz8ZIfb
> N+REZxcDTVdCdoblr2tQOH4PEKIuLGv7pBQPVUVKBxxCZCUBMYUJHXZvgcX7akFP
> xfRxcXlhmxgVsQFvBC7nJVLiEbcpP09wur7HMz/ck5jFqg9v+8F9I4E749Db84o=
> =LTPl
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20130821/36063b56/attachment-0002.html>