[Oisf-users] Questions about stats and packet drops

[Jose Vila]

Thanks Cooper, answers inline.


On Wed, Jan 7, 2015 at 4:52 PM, Cooper F. Nelson <cnelson at ucsd.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/7/2015 5:44 AM, Jose Vila wrote:
> > Thanks Cooper for your reply.
> >
> > I've added more cores, reducing the drop rate below 2%. Can't add BPF
> > filters as the network is heterogeneous and I want to catch as much
> > traffic as possible, despite its src/dst port (I have detected some
> > webservices in weird ports).
> >
> > I still have the same questions I posted in my first mail:
> >
> > * What does exactly "tcp.reassembly_memuse" mean and in which units it
> > is measured? If it's measured in bytes I'm getting more than 18 Exabytes
> > of memory usage !!!
>
> How much memory suricata is using for reassembling TCP streams.  It
> should be in bytes, I'm seeing number's like this:
>
> tcp.reassembly_memuse     | AFPacketeth21             | 824201958
> tcp.reassembly_memuse     | AFPacketeth22             | 824201958
>
> ...which I believe is in bytes.
>

I'm using PF_RING and getting this values for tcp.reassembly_memuse right
now:
tcp.reassembly_memuse     | RxPFRbond01               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond02               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond03               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond04               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond05               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond06               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond07               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond08               | 18446744073431298171
tcp.reassembly_memuse     | RxPFRbond09               | 18446744073431298171

As I said before, pretty close to 2^64 = 18446744073709551616

Exactly, 278253445 bytes (265,36MB) away.



> > * I believe "tcp.segment_memcap_drop" means packets received by suricata
> > (thus counted in "capture.kernel_packets") but couldn't get to the
> > (stream or reassembly?) processor for further treatment. Which processor
> > is the right one? How can I reduce its value?
>
> I think that is right, my counters are all zeroes.  I suspect if you are
> having drops here use should use larger ring and socket buffers for your
> worker threads.  Here are my settings:
>
> >     ring-size: 500000
> >     buffer-size: 1048576
>
>
I've had some problems with this options before. Giving a too large number
made Suricata unable to start in my config.

Anyway I'm giving it another shot to see if I can rise their value and get
Suri to work.


> > * I believe "tcp.stream_depth_reached" gets incremented each time the
> > "stream.reassembly.depth" is reached, but no packets are dropped here,
> > they are passed to other processors for further inspection without being
> > reassembled. Is this right?
>
> Nope.  "tcp.stream_depth_reached" means you have tracked a stream to the
> maximum depth and are not processing any further packets.  This is
> defined by the 'depth:' directive under "stream:".
>

So the segment of the stream that passes "depth" size is simply discarded
without inspection?


> > * What does exactly "tcp.reassembly_gap" mean?
>
> I think it means that TCP segments were missing when reassembling a
> stream, but I may be wrong about that.
>
> > Thank you very much,
> >
> > Regards,
> >
> > Jose Vila.
> >
> >
> > On Sun, Jan 4, 2015 at 4:57 PM, Cooper F. Nelson <cnelson at ucsd.edu
> > <mailto:cnelson at ucsd.edu>> wrote:
> >
> > Couple things you could try.
> >
> > 1.  Use all available cores (12 workers threads).
> >
> > 2.  Use a bpf filter to only monitor ports 80 and 53
> >
> > On 12/24/2014 12:37 AM, Jose Vila wrote:
> >> Hi,
> >
> >> I'm playing around with Suricata, and want to reduce the number of
> drops.
> >
> >> I have 1000Mbits/s traffic and a server with 12 cores and 12GB of RAM.
> >> The objective of this sensor is to get HTTP and DNS logging and it only
> >> has a bunch of very simple rules for file extraction.
> >
> >> I'm using PF_RING, and recently switched to "workers" runmode, which
> >> reduced my packer drop rate (capture.kernel_drop statistic) to around
> >> 5-6% with 6 worker threads.
> >
> >> My memcaps are:
> >> defrag.memcap = 32mb
> >> flow.memcap = 256mb
> >> stream.memcap = 7gb
> >> stream.reassembly.memcap = 3gb
> >> stream.reassembly.depth = 8mb
> >
> >
> >
> >
> >
>
> - --
> Cooper Nelson
> Network Security Analyst
> UCSD ACT Security Team
> cnelson at ucsd.edu x41042
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (MingW32)
>
> iQEcBAEBAgAGBQJUrVY+AAoJEKIFRYQsa8FWpcIIAL84zr5mmV5rD6RPlHhjCcyl
> ngiDYDSDiqlVtCTbtcdjkrF3x/TwV2J1wXyM6x2Db1PAJCHip0s8lrs5a5G42xJM
> P8yw5Sr4z3Mxj6lxm0W1RcUWs5PK03AgnAdiHl28aoMs+TFgWmOeKcgDPeAGHkBx
> Dj30AYhP6CL32r6OTEHEFzisv7q0Cl6hMereSwad3p3oouqK2OJEhfvBCXO+dPlS
> SWHqdWnGca/Yr0sy1LbF5cN3RdNjhS1+8MDyYqpHxrQOlLqFKFePr9/4+ra3K8wM
> SbTi877B+WJJtoNNhEwn9PCjFs1JVCd4M++0OLG/PLZchVsXpKurBROY7UaY12E=
> =JsJu
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150107/1874a874/attachment-0002.html>