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

[Cooper F. Nelson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've used netstat in the past as it will show a 'Recv-Q' column, but
this doesn't work in monitor mode as the connections aren't established.

I use this command to monitor kernel drops from the stats.log file:

>  watch "tail -n 730 stats.log | fgrep kernel"

As I mentioned, if I set a buffer in AF_PACKET mode I will drop packets
immediately when suricata starts.  With no buffers set I only drop
packets when monitoring a large volume single flow.

Here is an example for today.  Overall packet drops are under 1%, which
I think is acceptable.

> Every 2.0s: tail -n 730 stats.log | fgrep kernel             Wed Aug 14 19:48:51 2013
> 
> capture.kernel_packets    | AFPacketeth21             | 293827654
> capture.kernel_drops      | AFPacketeth21             | 790209
> capture.kernel_packets    | AFPacketeth22             | 298450539
> capture.kernel_drops      | AFPacketeth22             | 1019252
> capture.kernel_packets    | AFPacketeth23             | 318326859
> capture.kernel_drops      | AFPacketeth23             | 532196
> capture.kernel_packets    | AFPacketeth24             | 308335735
> capture.kernel_drops      | AFPacketeth24             | 296629
> capture.kernel_packets    | AFPacketeth25             | 315722475
> capture.kernel_drops      | AFPacketeth25             | 1315421
> capture.kernel_packets    | AFPacketeth26             | 293641415
> capture.kernel_drops      | AFPacketeth26             | 105225
> capture.kernel_packets    | AFPacketeth27             | 336858377
> capture.kernel_drops      | AFPacketeth27             | 2523771
> capture.kernel_packets    | AFPacketeth28             | 297024185
> capture.kernel_drops      | AFPacketeth28             | 972209
> capture.kernel_packets    | AFPacketeth29             | 298489197
> capture.kernel_drops      | AFPacketeth29             | 344422
> capture.kernel_packets    | AFPacketeth210            | 299833503
> capture.kernel_drops      | AFPacketeth210            | 898988
> capture.kernel_packets    | AFPacketeth211            | 323157271
> capture.kernel_drops      | AFPacketeth211            | 2994375
> capture.kernel_packets    | AFPacketeth212            | 315649281
> capture.kernel_drops      | AFPacketeth212            | 1329285
> capture.kernel_packets    | AFPacketeth213            | 308327722
> capture.kernel_drops      | AFPacketeth213            | 2369047
> capture.kernel_packets    | AFPacketeth214            | 294967385
> capture.kernel_drops      | AFPacketeth214            | 233821
> capture.kernel_packets    | AFPacketeth215            | 324474054
> capture.kernel_drops      | AFPacketeth215            | 6854983
> capture.kernel_packets    | AFPacketeth216            | 292958116
> capture.kernel_drops      | AFPacketeth216            | 44432
> 

On 8/14/2013 12:37 PM, Tritium Cat wrote:
> 
> By the way, is there a way to profile how well these types of settings are
> performing ?  (e.g. what is the current rmem utilization ?)  I was thinking
> SNMP might be a great help but I've not spent any time on it.
> 
> 

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/

iQEcBAEBAgAGBQJSC+DuAAoJEKIFRYQsa8FWhGIIAMi9ImKHJZXgEEg2zABccnZr
Lfmy6aE+3jwgslqJ/yzKuW29XH3bS0YIuaSyfOSxQDQVX1Fc9q0Xx33f4uwsCsUx
fJevMMGwRQyHyhPHHsJ3CIQSj5rXzZLp/L9560oGw0iv6AOmE79yeXwm3oS/kxTo
81cszeV9mwP55A0J5d+rPDS+Yg5NQYGmAD+VNtIL9k2u2PgK+UuNCrleEZpjegyY
YeboVYJ0yFNoHJndGoveIA52fyP0KjGCXi9F20cdgIQclHykP46IojuFyXqBARny
sgWq19c3MvkMY4mxFyUk4GN0fFotIl+9rPn8WLEV6GhAYqRK1o1AwFYgMYrsTDc=
=tXOy
-----END PGP SIGNATURE-----