[Oisf-users] defrag afpacket

[Peter Manev]

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  -
https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt


Thank you




-- 
Regards,
Peter Manev