[Oisf-users] tcp.segment_memcap_drop

Peter Manev petermanev at gmail.com
Wed Jun 11 18:29:52 UTC 2014


On Wed, Jun 11, 2014 at 3:52 PM, Kurzawa, Kevin
<kkurzawa at co.pinellas.fl.us> wrote:
> This is Suricata version 2.0 RELEASE
>
> Yea, that number tcp.reassembly_memuse shot up the other day suddenly. I restarted Suricata yesterday afternoon and here are the new relavent numbers.
>
> -------------------------------------------------------------------
> Date: 6/11/2014 -- 09:11:12 (uptime: 0d, 16h 08m 30s)
> -------------------------------------------------------------------
> Counter                   | TM Name                   | Value
> -------------------------------------------------------------------
> capture.kernel_packets    | RxPcapbond01              | 405967168
> capture.kernel_drops      | RxPcapbond01              | 449953
> capture.kernel_ifdrops    | RxPcapbond01              | 0
> tcp.sessions              | Detect                    | 4552548
> tcp.ssn_memcap_drop       | Detect                    | 0
> tcp.segment_memcap_drop   | Detect                    | 8401072
> tcp.stream_depth_reached  | Detect                    | 3298
> tcp.reassembly_memuse     | Detect                    | 8589934576
> tcp.reassembly_gap        | Detect                    | 1902749
>
> My related entries from suricata.yaml:
>
> stream:
>   memcap: 2gb
>   reassembly:
>     memcap: 2gb
>     depth: 1mb
>
> I checked my memory usage and am at 3gb out of 8gb's at the time of the above statistics.
>
> I'm assuming that the tcp.reassembly_memuse not what I think it is. It shows 8.5gb's at the moment but ... not sure why. Is there a bug or some error between the chair and the keyboard?
>
> Where does the tcp.reassembly_gap come into play with these numbers also?

Tcp gap  means your not seeing the whole tcp stream traffic (there are
gaps in the tcp stream/s), that could also relate to drops.
1902749 is a lot of gaps in my opinion for 16 hrs.

What is the reason  you use pcap mode?

>
>
> -----Original Message-----
> From: oisf-users-bounces at lists.openinfosecfoundation.org [mailto:oisf-users-bounces at lists.openinfosecfoundation.org] On Behalf Of Victor Julien
> Sent: Tuesday, June 10, 2014 4:39 AM
> To: oisf-users at lists.openinfosecfoundation.org
> Subject: Re: [Oisf-users] tcp.segment_memcap_drop
>
> On 06/09/2014 04:50 PM, Kurzawa, Kevin wrote:
>> Regarding the statistic tcp.segment_memcap_drop
>>
>>
>>
>> What is this statistic compared to?
>>
>> tcp.ssn_memcap_drop is compared to tcp.sessions
>>
>> capture.kernel_drops is compared to capture.kernel_packets
>>
>> But what is tcp.segment_memcap_drop compared to?
>
> It relates to tcp.reassembly_memuse. If the tcp.segment_memcap_drop counter is increased, it means that the stream engine is out of reassembly memory.
>
>>
>>
>> What should this drop rate be? Under 1% like the capture.kernel_drops?
>
> Ideally it's 0.
>
>> tcp.reassembly_memuse            | Detect                    |
>> 18446744073420130184
>
> This value looks like a bug here. What suri version are you running?
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/



-- 
Regards,
Peter Manev



More information about the Oisf-users mailing list