[Oisf-users] defrag afpacket

Peter Manev petermanev at gmail.com
Mon May 21 12:10:56 UTC 2018

On Mon, Apr 30, 2018 at 11:36 AM, Kerry Milestone
<Kerry.Milestone at ed.ac.uk> wrote:
> Hello,
> wondering if someone might be able to clarify this a bit for me.
> in the afpacket settings, there is:
> "In some fragmentation case, the hash can not be computed. If "defrag"
> is set to yes, the kernel will do the needed defragmentation before
> sending the packets.
> defrag: yes"
> and there is also the general defrag settings.
> "defrag:
>   memcap: 32mb
>   hash-size: 65536
>   trackers: 65535 # number of defragmented flows to follow
>   max-frags: 65535 # number of fragments to keep (higher than trackers)
>   prealloc: yes
> timeout: 60"
> If the primary reason for afpacket to pass packets directly to the
> application, will having the kernel defrag packets hit performance or is
> this actually more efficient getting the prepared packets off the wire
> for suri?  What are the 'some fragmentation case' where this is relevant?

I am not sure what exactly the reason was but  I get into the habit of
switching it off (defrag: no) and leaving it up to suricata (indicator
to switch that off could be seeing  something like "max packet size -
25000" - in stats.log aka much bigger packet size than the set up
MTU/default packet size)

> Where one receives an awful lot of rather small fragments of varying
> legitimacy and volume bursts, is this something which can be absorbed in
> the buffer-size, block-timeout etc settings (IDS only)?

I think Eric is about to cook  a patch for this  - buffer-size - you
can disregard this setting for afp-v3

Some useful info on AFPv3 and its specifics/fields/variables  -

Thank you

Peter Manev

More information about the Oisf-users mailing list